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Foreword 


This  document  has  been  prepared  by  the  Naval  Coastal  Systems  Center, 
Remote  Minehunting  System  project.  It  represents  an  initial,  tailored 
implementation  of  the  Logisitic  Support  Analysis  ( LSA)  and  Logistic 
Support  Analysis  Record  ( LSAR)  requirements  for  the  RMS  program.  This 
document  is  inteneded  to  be  dynamic.  The  RMS  system  is  in  its  initial 
development.  This  document  will  be  updated  as  that  direction  and 
guidance  becomes  available. 
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Remote  Minehunting  System 
LSA  Strategy 


1 . 0  INTRODUCTION 

Logistic  Support  Analysis  (LSA)  is  a  systematic  approach  to  the  design 
cf  supportable,  affordable  systems  and  equipments.  It  employes  a 
defined  set  of  analyses  and  documentation  requirements  that  are  used  to 
identify  and  isolate  those  elements  of  a  hardware  or  support  system 
design  which  have  the  gratest  or  most  critical  impact  on  system 
supportagility.  Supportability ,  in  this  context,  is  the  relationship 
between  hardware  and  support  system  characteristics  as  they  relate  to 
the  operational  availability  and  affordability  (Life  Cycle  Cost)  of  the 
RMS . 

The  LSA  process  is  made  up  of  two  main  components.  The  first  is  the 
technical  analyses  or  tasks  which  are  used  to:  (1)  Define  system 
requirements  and  constraints ;  ( 2 )  Identify  support  characteristics  of 
a  hardware  design,  and  (3)  Design  the  optimum  support  system  associated 
with  an  acceptable  design.  The  second  component  of  the  LSA  process  is 
the  capture  of  the  resulting  documentation.  This  documentation  process, 
called  the  Logistic  Support  Analysis  Record  ( LSAR) ,  is  a  structured 
approach  to  the  capture ,  storage ,  and  use  of  information  developed 
through  the  conduct  of  the  LSA  Tasks.  MIL-STD-1388-1A  defines  the 
analysis  tasks  of  an  LSA  Program.  MIL-STD-1388-2A  establishes  the 
attendant  LSAR  documentation  requirements.  To  be  cost-effective  the 
LSA/LSAR  must  be  tailored  to  the  unique  needs  and  considerations  of  an 
development  program. 

This  LSA  Strategy  reflects  a  tailored  implementation  of  the  basic 
standards  for  the  RMS  and  contains  the  specific  tasks  to  be  conducted 
and  the  procedures  to  be  used  for  documenting  their  results  in  the  LSAR. 

1 . 1  PURPOSE 

• 

The  RMS  LSA  Program  is  designed  to  establish  a  realistic  balance  between 
RMS  hardware  and  support  system  design  characteristics  to  meet  system 
operational  and  affordability  requirements  and  constraints.  The  RMS  LSA 
Program  is  based  on  the  tailored  implementation  of  MIL-STD-1388-1A  and  - 
2A  as  reflected  in  the  NAVSEA  Logisitic  Support  Analysis  Implementation 
Guide. 

LSA  is  a  dynamic  process  requiring  support  from  a  diverserse  set  of 
engineering  and  functional  support  disciplines.  The  process  has  been 
tailored  to  focus  NCSC  LSA  resources  on  those  aspecrts  of  the  emerging 
hardware  and  support  system  designs  which  offer  the  greatest  opportunity 
for  significant  supportability  improvement  and  the  best  return  on 
investment.  The  program  documentation,  captured  in  the  LSAR,  will 
reflect  the  Program  decisions  based  upon  the  results  of  the  analytical 
program. 
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The  NCSC  RMS  LSA  Program  is  positioned  within  the  RMS  System  Engineering 
organization  so  as  to  be  an  active  and  contributing  participant  in  the 
system  level  analyses  and  decisions  which  potentially  impact  system 
availability,  logistic  support  and  affordability.  Rigorous  integration 
of  common  analysis  and  documentation  requirements  within  the 
supportability  organization  has  resulted  in  an  LSA  Program  that  is  cost 
effective  and  focused,  but  sufficiently  flexible  to  adapt  to  the 
changing  needs  of  the  RMS. 

This  LSA  Strategy  has  been  prepared  by  NCSC  to  ensure  that  the  LSA 
Program  activities  are  conducted  in  a  disciplined  and  timely  manner  and 
are  technically  consistent  with  RMS  goals  and  objectives.  The  strategy 
establishes  common  procedures  for  performing  LSA  analytical  tasks  and 
for  preparation  of  the  LSAR  documentation. 

The  strategy  will  be  updated  throughout  the  program  to  reflect  the  most 
technically  responsive  and  cost  effective  approach  to  the  implementation 
of  LSA  for  RMS. 

1.2  SCOPE. 

This  plan  is  applicable  to  NCSC,  other  activities  involved  in  RMS 
development,  subcontractors  and  vendors  responsible  for  accomplishment 
of  the  RMS  LSA  Program.  The  procedures  contained  in  this  plan  are 
applicable  to  the  RMS  equipment  to  include  all  subsystems  and 
equipments.  The  LSA  Tasks  will  be  performed  iteratively  concurrent  with 
the  evolution  of  the  RMS  hardware  and  support  system  designs.  The  LSAR 
will  be  updated  continuously  to  reflect  the  most  current  information 
available.  The  LSAR  database  will  serve  as  the  source  documentation  for 
development  of  all  deliverable  logistics  products. 

1 . 3  OBJECTIVES . 

The  RMS  LSA  Program  unites  the  Integrated  Logistic  Support  (ILS)  Program 
with  the  Design  and  Systems  Engineering  efforts  from  program  initiation 
through  operational  support  of  the  deployed  RMS.  The  blending  of 
performance,  engineering  and  logistic  support  development  activities 
ensures  that: 

a.  Supportability  considerations  influence  system  requirements  and 
designs. 

b.  Support  requirements  are  optimally  related  to  the  C&TS  design  and 
to  each  other. 

c.  All  support  resuource  requirements  are  identified  and  quantified. 

d.  Logistics  products  reflect  hardware  and  support  system  design 
characteristics . 

e.  RMS  is  supportable  and  affordable  throughout  the  operational 
life. 
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2.0  RMS  SYSTEM  DESCRIPTION 


The  U.S.  Navy  has  the  requirement  to  perform  Remote  Minehunting 
operations  to  include  detecting,  and  localizing  mines  (and  mine  like 
objects).  Capable  of  providing  a  rapid  response  capability  to 
requirements  of  U.S.  Navy  Battle  Groups,  the  RMS  will  provide  a 
sustained  forward  presence  in  operational  areas,  egress  and  exit  lanes, 
will  ensure  safe  operations  in  economic,  logistic  shipping  and  port 
locations,  and  maintain  open  operations  of  critical  ports. 

Still  in  Concept  Formulation,  the  RMS  (Figure  2-1)  is  envisioned  as 
an  autonamous  system  designed  for  real-time  operation.  Further 
information  regarding  performance  requirements  and  desigm  considerations 
are  available  in  the  Remote  Minehunting  System  Technical  Operational 

Requirements  (TOR)  dated  _  available  upon  request  from  the 

Naval  Coastal  Systems  Center  (Code  3120). 

The  RMS  is  an  Acquisition  Category  (ACAT)  _  project  being 

developed  in  response  to  the  requirements  of  Navy  Operational 

Requirement  (OR)  _ .  The  RMS  is  being  designed  and  built  at  NCSC, 

Panama  City  Florida.  Upon  completion,  the  RMS  and  its  support  package 
will  be  turned  over  for  oest  and  evaluation  activities  by  the 

_ Following  an  approximate  _  month 

evaluation  period,  _  will  assume  responsibility  for  RMS 

operations  and  maintenance. 

The  RMS  is  a  unique  system  designed  to  operate  on  Fleet  ships  and 
crafts  of  opportunity  and  to  operate  independently  of  platform  power. 
The  objective  of  this  project  is  to  develop  an  RMS  system  capable  of 
worldwide  operations;  therefore,  a  logistic  support  system  tailored  co 
a  team  operations  and  maintenance  concept  is  a  primary  consideration. 
Required  characteristics  are  still  in  development  and  will  be  provided 
in  Table  2-1  upon  their  becoming  available. 

2.1  RMS  SUBSYSTEMS. 

The  RMS  is  comprised  of  seven  functional  subsystems.  The  following 
is  a  brief  description  of  those  subsystems.  M«_re  in-  depth  information 
is  available  in  the  RMS  Technical  Operational  Requirements  dated 


2.1.1  SENSOR  VEHICLE  SUBSYSTEM 

2.2.2  TOWING  VEHICLE  SUBSYSTEM 

2.1.3  CONTROL  STATION  SUBSYSTEM 

2.1.4  DEPLOYMENT  AND  RECOVERY  SUBSYSTEM 

2.1.5  AUXILIARY  EQUIPMENT  SUBSYSTEM 
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Figure  2-1 
RMS  System  Concept 
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3.0  LSA  PROGRAM  MANAGEMENT 


LSA  Program  Management  responsibility  for  the  NCSC  RMS  LSA  Program  is 
vested  in  the  System  Effectiveness/Integrated  Logistic  Support  (SE/ILS) 
organization  located  in  the  NCSC  RMS  Project  Office,  Panama  city  Beach, 
Florida.  The  organizational  structure  is  as  depicted  in  Figure  3-1 


3.1  RMS  PROGRAM  MANAGER 

Program  Management  responsibility  for  the  RMS  system  is  vested  in  the 
RMS  Program  Manager,  NCSC  Code  3120.  The  RMS  Program  Manger  is 
responsible  for  overall  program  planning,  programming,  budgeting  and 
direction  of  the  activities  required  to  transform  the  operational 
requirement  into  the  design  specifications  and  subsequently  into  the  RMS 
System. 

3.2  SYSTEM  EFFECTIVENESS/INTEGRATED  LOGISTIC  SUPPORT  RESPONSIBILITIES 

The  NCSC  RMS  System  Effectiveness/Integrated  Logisitic  Support  (ILS/SE) 
organization  is  responsible  for  the  management  and  control  and  execution 
of  all  RMS  LSA  activities.  NCSC  Code  3120  (LSA)  provides  technical 
support  to  the  RMS  SE/ILS  Manager  in  the  performance  of  the  RMS  LSA 
Program  and  in  the  management  of  government  and  vendor  LSA  activities. 
The  SE/ILS  orgranization  is  responsible  for  development  and  maintenance 
of  the  RMS  LS AR  database  to  include  the  incorporation  of  all  vendor  LSAR 
data. 
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Figure  3-1 

RMS  LSA  Program  Organization 
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4.0  LSA  PROGRAM  DESCRIPTION 


Effective  integration  of  ILS  planning  and  development  activities 
involves  both  horizontal  and  vertical  integration.  The  LSA  process 
provides  the  technical  vehicle  for  implementation  of  this  Integrated 
approach.  Horizontally,  the  LSA  program  has  been  integrated  with  the 
ILS  and  other  supportability-related  program  elements.  Vertical 
integration  amoung  the  ILS  functional  disciplines  likewise  has  been 
implemented  to  coordinate  support  system  development  activities. 

RMS  LSA  program  activities  for  achieving  maximum  RMS  system 
supportability  at  minimum  risk  are  based  upon  the  use  of  a  common  set 
of  operating  procedures.  These  procedures  reflect  the  integration  of 
RMS  Design,  Systems  Engineering  and  ILS  activities.  They  elemeinate 
duplicate  and  redundant  activities  and  documentation,  improve  the 
coordination  and  consistancy  of  functional  element  activities  and 
enhance  the  quality  of  the  support  products. 

Us  of  these  procedures  will  ensure  the  timely  identification  of 
supportability  and  manpower  and  personnel  issues  concurrent  with  the 
formulation  of  design  concepts  and  alternatives.  Through  continuous 
involvement  in  the  maturation  of  the  design,  NCSC  RMS  SE/ILS 
organization  is  able  to:  (1)  Establish  design  goals  and  objectives 
derived  from  analysis  of  predecessor  systems  and  equipments;  (2) 
Evaluate  the  adequacy  of  proposed  design  solutions,  and;  (3)  Identify 
opportunities  for  further  improvement  of  the  emerging  hardware  and 
support  system  concepts  and  designs. 

Rigorous  adherence  to  the  established  integration  procedures  is  a 
fundamental  element  of  a  total  quality  approach  and  is  an  essential 
aspect  of  the  NCSC  concurrent  engineering  approach  to  the  RMS 
development.  Each  of  the  individual  SE/ILS  organization  elements  have 
specific  program  responsibilities  as  defined  in  the  program  management 
plans.  These  responsibilities  are  described  in  terms  of  detailed 
technical ,  analytical  and  documentation  requirements  whose 
accomplishment  support  the  overall  program  objectives.  When  the  total 
set  of  functional  requireemnts  is  outlined  it  is  readily  apparent  that 
there  is  significant  commonality  or  overlap  betwen  the  needs  of  the 
individual  communities.  Common  analysis  and  documentation  requirements 
have  been  identified  and  a  single  organizational  element  assigned 
responsibility  for  their  accomplishment.  The  results  are  then  made 
available  to  all  participating  organizations. 

The  results  of  the  LSA  Tasks  are  captured  in  the  RMS  Logistic  ADP 
system.  Access  to  the  LAS  information  provides  all  users  with  the  most 
current  data  necesary  to  conduct  their  area-specific  program  tasks. 
This  approach  is  a  practical  implementation  of  the  "create  once,  use 
many  times"  concept.  In  addition  to  the  capture  and  dissemination  of 
supportability  data  among  the  individual  communities,  the  LAS  database 
serves  as  a  planning  and  tracking  system  for  management  of  the  RMS  LSA 
program. 
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LSA  is  an  iterative  process  that  commences  with  the  establishment  of 
supportability  requirements  and  constraints  for  hardware,  software  and 
support  system  designs  by  the  Navy.  These  top  level  requirements  are 
further  allocated  to  lower  level  components  and  support  elements  by 
NCASC  and  the  RMS  Program  organization.  As  RMS  component  design 
alternatives  are  developed,  the  LSA  process  is  used  to  identify  and 
quantify  hardware  design  characteristics  which  impact  on  the  support 
constraints,  as  well  as,  defining  the  support  requirements  of  the  RMS 
design.  These  defined  support  requirements  provide  the  basis  for  design 
of  the  RMS  support  system  within  the  Navy's  three  level  maintenance 
support  concept. 

The  LSA  database  captures  and  interrelates  the  RMS  system  supportability 
characteristics.  This  information  is  used  to  identify  and  quanitfy  the 
support  resource  requirements  associated  with  thte  hardware  design  and 
the  planned  support  concept.  Through  the  use  of  the  integrated  LSAR 
database,  deficiencies  in  the  supportability  characteristics  are 
highlighted  for  consideration  of  alternative  design  approaches  and/or 
alternative  support  concepts.  Upon  completion  of  the  hardware  and 
support  system  design  processes ,  the  LSAR  database  is  used  to  develop 
the  various  logistics  products  ensuring  consistency  of  the  individual 
products  with  the  hardware  design  and  with  each  other. 

The  following  subparagraphs  describe  the  analysis  and  documentation 
procedures  and  responsibilities  as  implemented  by  NCSC.  They  address 
the  requirements  for  both  the  horizontal  and  vertical  integration.  The 
discussion  includes  non-ILS  functions  of  the  supportability-related 
program  elements  in  order  to  fully  define  the  LSA  Program. 


4.2  LSA  TASK  SUMMARY. 

The  tailored  LSA  program  for  RMS  consists  of  the  MIL-STD-1388-1A  tasks 
shown  in  Figure  4-2.  The  primary  focus  of  the  current  RMS  LSA 
activities  is  directed  at  the  "Front-End-* Analysis"  portion  of  the  LSA 
process.  The  goal  is  the  achievement  of  demonstratable  influence  on  the 
emerging  RMS  hardware  design.  The  primary  objective  is  to  define  and 
quantify,  specific  supportability  goals,  constraints  for  the  RMS 
hardware  system  resulting  in  the  optimum  balance  of  system  availability 
and  cost  characteristics. 

In  addition  to  the  focus  on  influence  of  the  RMS  design  will  be  proof 
of  the  RMS  support  concept  of  "three  level  maintenance".  This  support 
concept  consists  of:  (1)  At-Sea  Organizational  and  At-Sea  Intermediate 
repair  to  include  replacement  of  electronic  modules,  circuit  card 
assemblies  (CCAs),  light  bulbs/indicators,  and  fuses;  connector 
replacement  and  cable  repair;  and  engine  servicing  to  include  refueling, 
and  oil/air  filter  replacement;  (2)  Intermediate  Maintenance;  and  (3) 
Depot.  The  LSA  Program  will  assess  the  effects  of  alternative  RMS 
equipment  and  support  system  designs  on  the  support  concept  based  on 
their  impacts  with  regard  to  types  and  quantities  of  support  resources. 
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Task  102,  LSA  Plan 

Task  103,  Program  and  Design  Reviews 
Task  201,  Use  Study 

Task  202,  Supportability  Constraints 

Task  301,  Functional  Requirements  Identification 

Task  302,  Support  System  Alternatives 

Task  303,  Evaluation  of  Alternatives  and  Tradeoff  Analysis 
Task  401,  Task  Analysis 

Task  501,  Supportability  Test,  Evaluation  and  Verification 

Figure  4-1 

LSA  Task  Requirements 
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costs,  and  the  operational  availability  of  the  RMS  system.  The  LSA 
program  will  identify  and  evaluate  supportability  risk  associated  with 
alternative  concepts  for  both  hardware  and  support  system  designs. 

The  LSA  program  is  used  to  influence  the  RMS  system  requirements  and 
designs  for  supportability  and  ensures  development  of  the  optimum 
support  resource  requirements.  ILS  identifies  ten  separate  elements  of 
support  which  can  be  generally  divided  into  two  categories.  The  two 
categories  are  Support  Resource  Drivers  and  Support  Resources.  During 
the  current  development  activirties ,  the  LSA  Program  concentration  is 
on  the  Support  Resource  Driver  category  to  maximize  supportability 
influence  on  the  RMS  design.  Trade-offs  in  the  Support  Resource  Driver 
area  will  assess  and  evaluate  their  impacts  in  terms  of  types  and 
quantities  of  support  resources  required.  Trade-off  criteria  is  being 
established  to  highlight  predicted  hardware  characteristics,  isolate 
potential  deficiencies  and  identify  opportunities  for  improvements  in: 
Reliability  (fewer  support  actions).  Maintainability  (less  complexity) 
and  operability  (ease  of  use  and  support)  as  they  relate  to  Life  Cycle 
Costs.  The  Support  Resource  Driver  elements  of  ILS  include: 

a.  Design  Influence 

b .  Maintenance  Planning 

c.  Manpower  and  Personnel 

d .  Standardization/Interoperability 

e .  Transportation/Transportability 

The  characteristics  of  the  RMS  system  design  with  regard  to  these  five 
elements  are  used  to  drive/establish  system  requirements. 

As  the  design  matures  the  LSA  activities  will  shift  their  emphasis  from 
influencing  the  design  to  design  and  optimization  of  the  support  system. 
These  activities  are  primarily  aimed  at  the  identification  and 
quantification  of  support  resources  for  each  of  the  Support  Resource 
elements  of  ILS.  This  information  is  provided  via  the  LSAR  to  the 
individual  element  managers  so  that  appropriate  steps  can  be  taken  to 
finalize  the  logistics  products  and  procure  the  required  resources 
needed  for  operational  support.  Figure  4-2  depicts  the  breakout  of  ILS 
elements  by  category. 


SUPPORT  RESOURCE  DRIVERS 

Design  Influence 
Maintenance  Planning 
Manpower,  Personnel** 
Standardization/Interoperability 


SUPPORT  RESOURCES 

Supply  Support 

Support  &  Test  Equipment 

Technical  Publications 

Packaging,  Handling,  Storage  & 

Transportation 

Facilities 

Computer  Resources  Support 
Training  and  Training  Support 


**  Both  Categories 


Figure  4-2.  Categories  of  ILS  Elements 
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4.2  LSA  TASK  PROCEDURES  . 


The  RMS  program  is  in  early  concept  development.  For  this  reason,  the 
discussions  of  the  LSA  Program  Tasks  must  address  the  considerations  of 
all  of  the  acquisition  program  phasdes,  namely  Concept  Exploration  & 
Definition,  Demonstration  &  Validation,  Engineering  &  Manufacturing 
Development  and  Production  &  Deployment.  Consequently,  within  each  of 
the  Task  Section  writeups  this  plan  deals  with  the  principal  program 
considerations  relative  to  the  individual  program  phase  or  state  of  the 
hardware  design.  It  is  encumbent  upon  the  user  of  this  guid  to 
determine  the  appropriate  phase  relative  to  the  hardware  design  and 
employ  the  guidance  provided  for  a  Task  in  that  phase  in  order  to 
properly  define  and  implement  the  LSA  Tasks.  When  the  LsA  for  a 
particular  hardware  component  is  initiated  after  the  start  of  the  design 
proces  the  user  should  review  the  guidance  for  the  phases  preceding  the 
current  design  phase  to  determine  what  activities  or  decisions  have  or 
should  have  transpired  so  that  the  LSA  program  can  be  properly  oriented. 

4.2.1  Task  Section  100,  Program  Planning  and  Control 


4. 2. 1.1  Concept  Exploration  &  Definition 

Selected  portions  of  LSA  Task  Section  100  which  are  appropriate  for  the 
conceptional  design  stage  of  a  hardware  development  are  defined  in  the 
following  paragraphs.  The  Tasks  described  are  those  associated  with  the 
Performing  Activity  (NCSC)  and  do  not  include  Tasks  which  should  be 
accomplished  by  the  Requiring  Activity  (PMS407). 

a.  Task  102  -  LSA  Plan 

Definition. 

The  LSA  Plan  (DI-S-7017A)  describes  how  the  hardware  developer  of  the 
system  will  execute  the  LSA  program  •requirments  contained  in  a 
xolicitation  SOW.  It  provides  the  Requiring  Authority  with  visibility 
of  the  performing  organization's  approach  to  LSA.  In  fact,  if  the  plan 
is  requested  as  a  part  of  a  contractor's  proposal,  it  is  often  one  of 
the  considerationsd  for  source  selection  and  normally  becomes  a  part  of 
the  ensuing  contract.  For  major  programs,  the  LSA  plan  is  generally 
submitted  as  a  separate  document;  in  smaller  programs,  it  may  be 
submitted  as  part  of  the  contractor's  Integrated  Support  Plan  (ISP). 
Development  of  the  LSA  Plan  includes  performance  of  the  following  two 
subtasks : 

a.  Subtask  102.2.1  -  Prepare  LSA  Plan  (Concept  Phase) 

b.  Subtask  102.2.2  -  Update  the  LSA  Plan  (DEM/E&MD  Phases) 

Subtask  102.1.2  -  Prepare  the  LSA  Plan.  Performance  of  this  subtask 
which  will  yield  an  LSA  Plan,  begins  and  is  completed  in  the  CE  Phase. 
The  plan  includes  the  following  information: 
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a.  LSA  program  description. 

b.  LSA  program  management  structure. 

c.  Identification  of  LSA  tasks  and  how  they  will  be  performed. 

d.  LSA  task  accomplishment  schedule. 

e.  Description  of  how  LSA  tasks  and  resulting  data  will  interface 
with  other  ILS  and  system  engineering  elements  of  the  program. 

f.  Identification  of  items  upon  which  the  LSA  Tasks  will  be 
performed  (LSA  Candidate  List) 

g.  Explanation  of  the  LSA  control  numbering  system. 

h.  Description  of  how  supportability  and  supportability  related 
design  requirements  will  be  disseminated/coordinated  with  the 
system  designers  and  subcontractors. 

i.  Identificaion  of  data  needed  to  perform  LSA. 

j.  Description  of  procedures  for  updating  and  validating  LSA  data. 

k.  Identification  of  LSA  requirements  on  GFE/GFM. 

l.  Description  of  LSA  task  management  control  procedures. 

m.  Description  of  procedures  for  identifying  and  correcting  design 
problems  or  deficiencies  affecting  supportability. 

n.  Description  of  the  LSA  data  collection,  documentation  and 
dissemination  system. 

Task  Input. 

The  primary  input  to  this  subtask  is  Task  101  -  Early  LSA  Stragety.  The 
LSA  Strategy  is  normally  conducted  by  the  Requiring  Authority  and 
details  the  LSA  requirements  and  supporting  rationale  based  upon  program 
peculiar  considerations.  The  LSA  Strategy  forms  the  basis  for  the  SOW 
requirements  and  the  supportability  and  supportability-related 
requirements  of  teh  system  specification.  The  contractor  uses  that 
information  as  the  basis  for  preparing  the  Plan. 

Task  Output. 

The  output  of  this  task  is  the  contractor's  road  map  of  what  LSA  is  to 
be  accomplished  and  how  and  when  it  will  be  done. 

b.  Task  103  -  Program  and  Design  Reviews 

Definition. 

This  task  is  intended  to  assure  LSA  program  participation  in  the 
official  review  and  control  of  system  design  information;  the 
scheduling  of  detiled  LSA  program  reviews;  assessment  of  logistics  risks 
at  system  program  reviews;  and  integration  of  pertinent  aspects  of  the 
LSA  program  into  all  formal  program  and  design  reviews.  Such  reviews 
provide  an  important  mechanism  for  accomplishing  design  influence  and 
tradeoffs.  Task  103  is  divided  into  the  following  four  subtasks; 
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Space  Station  Freedom  C&TS 

o  Subtask  103.2.1  -  Establish  Design  Review  Procedures  (Concept) 

o  Subtask  103.2.2  -  Participate  in  Formal  System  Design  Reviews 

(DEM/VAL  and  FSD) 

o  Subtask  103.2.3  -  Participate  in  Formal  Program  Reviews  (DEM/VAL, 

FSD,  and  Production  Phases). 

o  Subtask  103.2.4  -  Participate  in  LSA/LSAR  Reviews  (DEM/VAL,  FSD, 

and  Production  Phases ) . 

Subtask  Procedures 

Subtask  103.2.1  -  Establish  Design  Review  Procedures.  Performance  of 
Task  103  during  the  Concept  Phase  generates  the  conduct  of  Subtask 
103.2.1.  This  subtask  is  designed  to  establish  procedures  within  the 
LSA  program  performing  activity  for  internal  review  of  system  design 
information  to  ensure  that  supportability  requirements  can  be  met.  It 
provides  supportability  specialists,  in  the  performing  organization, 
the  authority  needed  to  influence  design  and  tradeoffs. 

Input . 

The  contractor's  internal  organizational  structure  and  management 
procedures  are  the  primary  input  to  this  task. 

Output . 

Internal  procedures,  controls,  and  authorities  for  the  conduct  of 
this  type  review  will  generally  be  documented  in  the  LSA  Plan. 


4. 2. 1.2  Demonstration/Validation 

The  DEM/VAL  phase  consists  of  those  actions  required  to  verify 
preliminary  design  and  engineering,  accomplish  necessary  planning, 
analyze  trade-off  proposals,  resolve  or  minimize  logistics  problems 
identified  during  the  conceptual  phase,  and  validate  a  concept  for 
full-scale  development.  Advanced  development  prototypes  should  be 
used  and  tested  during  the  validation  phase  to  estimate  the  system's 
utility,  cost ,  environmental  impact,  safety,  human  engineering, 
operational  effectiveness  and  suitability  to  include  surety  and/or 
technological  factors;  and  to  refine  configuration  prior  to  entering 
FSD. 


a.  Task  102  -  LSA  Plan 

Performance  of  this  task  during  DEM/VAL  consists  of  accomplishing 
Subtask  102.2.2  -  Update  the  LSA  Plan,  as  required. 

Subtask  Procedure. 

Subtask  102.2.2  -  Update  the  LSA  Plan.  Using  analyses  results, 
program  schedule  modifications  and/or  program  decisions  made  since 
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the  LSA  Plan  was  completed  in  CE,  the  plan  will  be  appropriately 
updated  to  reflect  specific  efforts  to  be  accomplished  during  the 
DEM/VAL  Phase. 

Input . 

Requiring  Authority  updates  of  Task  101  -  Early  LSA  Strategy,  results 
of  LSA  Guidance  conferences,  and  any  modifications  to  the  program 
likely  to  affect  supportability  are  used  to  update  the  LSA  Plan 
during  this  phase. 

Output . 

An  up-to-date  LSA  Plan  that  reflects  the  planned  LSA  effort  for  the 
DEM/VAL  Phase.  The  plan  should  include  sufficient  detail  to  define 
the  current  program  and  carry  the  LSA  into  FSD. 

b.  Task  103  -  Program  and  Design  Reviews 

Performance  of  this  task  during  the  DEM/VAL  consists  of  active 
participation  of  supportability  specialists  in  system  design  reviews 
(Subtask  103.2.2),  formal  system  program  reviews  (Subtask  103.2.3), 
and  detailed  LSA/LSAR  program  reviews  (Subtask  103.2.4).  Procedures 
for  performance  of  each  DEM/VAL  Phase  subtask  axe  described  below. 

Subtask  Procedures 

Subtask  103.2.2  -  Participate  in  Formal  System  Design  Reviews. 
Performance  of  this  subtask  ensures  that  supportability  and 
supportability  design  requirements  are  specifically  considered  during 
each  formal  system  design  review,  e.g..  System  Design  Review  (SDR), 
Preliminary  Design  Review  (PDR),  Critical  Design  Review  (CDR) .  The 
primary  purpose  of  performing  this  task  is  to  assess  the  effect  of 
design  features  on  system  supportability,  cost  and  readiness  drivers, 
and  new/critical  logistics  support  resource  requirements . 

Input . 

Design  review  schedule  and  review  of  drawings  and/or  other  design 
data  that  will  be  subject  to  Requiring  Authority  review. 

Output . 

Agendas  for  and  documented  results  of  each  system  design  review  that 
specifically  addresses  supportability  issues. 

Subtask  103.2.3  -  Participate  in  Formal  Program  Reviews.  Periodic 
program  reviews  with  the  customer  are  an  integral  part  of  the  LSA 
Program  review  process.  It  is  an  opportunity  to  exchange  information 
and  obtain  specific  guidance  for  the  Requiring  Authority,  as  well  as, 
to  present  the  status  of  the  LSA  Program.  This  task  ensures  that  LSA 
program  status  forms  a  part  of  each  program  review,  whether  conducted 
internally  with  subcontractors  or  with  the  requiring  authority. 
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Input. 


Program  review  schedule  and  advance  notification  to  participants  of 
all  scheduled  program  reviews . 

Output . 

Agendas  for  and  documented  results  of  each  program  review  that 
specifically  addresses  supportability  issues. 

Subtask  103.2.4  -  Participate  in  LSA/LSAR  Reviews.  LSA  reviews 
identify  and  address  all  pertinent  aspects  of  the  LSA  program  to  a 
more  detailed  level  than  that  covered  at  design  and  program  reviews. 
Representative  discussion  items  include  LSA  task  results /status r  LSA 
data  and  its  documentation  in  the  LSAR,  design  and  supportability 
problems,  test  schedule  and  progress,  and  the  status  of 
subcontractors'  efforts.  LSA  reviews  are  conducted  as  part  of  ILS 
reviews  when  possible,  and  generally  are  specified/  scheduled  in  the 
SOW  for  Task  103.  This  subtask  also  includes  conduct  of  an  LSA 
guidance  conference  as  soon  as  possible  after  contract  award  to 
assure  a  thorough  and  consistent  understanding  of  the  LSA 
requirements  between  the  requiring  authority  and  performing  activity. 

Input . 

LSA  review  schedule  and  advance  notification  to  participants  of  all 
scheduled  LSA  reviews.  Data  packages  for  review  of  LSAR  documentation 
must  be  made  available  to  reviewers  for  preliminary  review  in  advance 
of  such  reviews.  Where  possible  this  information  should  be  made 
available  using  remote  access  capabilities  to  permit  on-line  access 
at  the  convenience  of  the  individual  reviewing  organizations. 

Output . 

Agendas  for  and  documented  results  of  each  LSA  review.  Another 
important  output  of  this  subtask  when  it’  includes  examination  of  LSAR 
is  the  approval  status  of  individual  LSAR  data  packages. 


4 . 2 . 1 . 3  Full  Scale  Development 

The  goal  of  the  FSD  Phase  is  to  produce  a  fully  tested,  documented, 
and  production-engineered  design  of  the  concept  selected  during 
DEM/VAL.  The  design  must  be  cost-effective,  operationally  suitable, 
producible,  and  logistically  supportable.  It  is  developed  through  an 
iterative  process  of  design-test-redesign.  The  final  product  is  a 
baseline  configuration  package.  Concurrently,  nonmaterial  aspects 
required  to  deploy  on  integrated  systems  are  developed,  refined,  and 
finalized.  An  essential  activity  of  the  FSD  Phase  is  that  of  adequate 
test  and  evaluation  by  the  Government  and  contractors. 

_ Task  102  -  LSA  Plan 

Performance  of  this  Task  during  FSD  consists  of  accomplishing  Subtask 
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102.2.2  -  LSA  Plan,  as  required. 

Subtask  Procedures. 

Subtask  102.2.2  -  Update  the  LSA  Plan.  Same  as  DEM/VAL. 
Input . 

Same  as  DEH/VAL. 

Output . 

Same  as  DEM/VAL. 


b.  Task  103  -  Program  and  Design  Reviews. 

Performance  of  this  task  during  FSD  entails  continued  participation 
by  supportability  representatives  in  system  design  reviews  (Subtask 
103.2.2),  formal  program  reviews  (Subtask  103.2.3),  and  LSA/LSAR 
reviews  (Subtask  103.2.4). 


4 . 2 . 1 . 4  Production 

The  primary  objective  of  this  phase  is  to  produce  efficiently  and 
deliver  to  the  operating  unit  an  effective,  supportable  system  in  a 
timely  manner  and  at  minimum  Cost. 

Selected  LSA  tasks  in  Series  100  -  Program  Planning  and  Control, 
Series  400  -Determination  of  Logistics  Support  Resource  Requirements, 
and  Series  500  -Supportability  Assessment,  defined  and  described 
below,  are  accomplished  in  this  phase. 

a.  Task  102  -  LSA  Plan 

• 

Performance  of  this  Task  during  PRoduction  consists  of  accomplishing 
Subtask  102.2.2  -  LSA  Plan,  as  required  in  order  to  insure  active 
participation  of  the  logistics  community  in  the  review  and  approval 
of  all  proposed  engineering  changes  developed  by  manufacturing. 

Subtask  Procedures. 

Subtask  102.2.2  -  Update  the  LSA  Plan.  Same  as  FSD. 

Input . 

Same  as  FSD. 

Output . 

Same  as  FSD. 

_ Task  103  -  Program  and  Design  Reviews 
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o  Subtask  301.2.2 
o  Subtask  301.2.3 
o  Subtask  301.2.4 
o  Subtask  301.2.5 
o  Subtask  301.2.6 
Subtask  Procedures. 


Unique  Functional  Requirements 
Risks 

Operations  and  Maintenance  Tasks 

Design  Alternatives 

Updates 


Subtask  301.2.1  -  Functional  Requirements.  The  purpose  of  this 
subtask  is  to  identify  the  functions  which  must  be  performed  to 
operate  and  maintain  the  system,  and  to  return  it  to  an  operational 
condition  after  a  malfunction. 


Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Subtasks 
203.2.1  -  Identify  Comparative  Systems,  203.2.2  -  Baseline  Comparison 
System,  Task  205  -  Support  Related  Design  Factors,  and  the 
Reliability,  Maintainability,  Safety  and  Human  Factors  Engineering 
Programs . 

Output . 

Performance  of  this  subtask  continues  into  DEM/VAL  and  is  an  input  to 
Subtask  301.2.2  -  Unique  Functional  Requirements  and  Task  302  - 
Support  System  Alternatives. 

Subtask  301.2.2  -  Unique  Functional  Requirements.  The  purpose  of  this 
subtask  is  to  analyze  the  functions  identified  in  Subtask  301.2.1  - 
Functional  Requirements  described  above.  The  analysis  reveals  those 
unique  support  requirements  for  the  new  system  stemming  from  new 
technology  or  deployment  concepts,  as  well  as  the  cost,  readiness,  or 
supportability  drivers. 

Input . 

Input  to  this  subtask  is  derived  from  Subtasks  203.2.1  -  Identify 
Comparative  Systems,  203.2.2  -  Baseline  Comparison  Systems,  Task  205 
•  Support  Related  Design  Factors,  ant  Subtask  301.2.1  -  Functional 
Requirements . 

Output . 

Performance  of  this  subtask  continues  into  DEM/VAL.  It  is  an  input 
to  Task  302  -  Support  System  Alternatives. 

Subtask  301.2.3  -  Risks.  The  purpose  of  this  subtask  is  to  analyze 
the  risks  associated  with  functions  identified  in  Subtask  301.2.1  - 
Functional  Requirements  and  301.2.2  -  Unique  Functional  Requirements. 
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Input . 


Input  to  this  subtask  is  derived  from  Subtasks  301.2.1  -  Functional 
Requirements  and  301.2.2  -  Unique  Functional  Requirements. 

Output. 

Performance  of  this  subtask  continues  intc  DEM/VAL  Phase  and  is  an 
input  to  Task  302  -  Support  System  Alternatives. 

Subtask  301.2.4  -  Operations  and  Maintenance  Tasks.  The  purpose  of 
this  subtask  is  to  identify  the  specific  tasks  which  must  be 
performed  in  satisfying  the  functional  support  requirements 
identified  in  Subtasks  301.2.1  Functional  Requirements  and  301.2.2  - 
Unique  Functional  Requirements.  Failure  Modes  and  Effects  Analysis 
(FMEA)  is  performed  by  the  Reliability  community  to  identify  the 
corrective  maintenance  tasks.  Additionally,  Reliability  Centered 
Maintenance  (RCM)  analysis  is  performed  to  identify  the  Preventive 
Maintenance  tasks.  Analysis  of  systems  operations  is  conducted  to 
identify  other  non-maintenance  support  tasks  which  must  be  planned. 

Input . 

Input  to  this  task  is  derived  from  Subtasks  301.2.1  -  Functional 
Requirements  and  301.2.2  -  Unique  Functional  Requirements. 

Output . 

Performance  of  this  subtask  continues  into  FSD.  Performance  of  this 
subtask  provides  data  for  entry  into  LSAR  sheets  B,  Bl,  B2  ,  C,  0, 
and  Dl,  and  is  an  input  to  Tasks  302  -  Support  System  Alternatives, 
and  401  -  Task  Analysis. 

Subtask  301.2.5  -  Design  Alternatives.  The  purpose  of  this  subtask  is 
to  use  the  functional  requirements  identified  earlier  in  the  first 
two  subtasks  as  a  basis  for  design  feedback  to  correct  design 
deficiencies . 

Input . 

Input  to  this  subtask  is  the  preceding  subtasks  of  this  task. 

Output . 

Performance  of  this  subtask  continues  into  FSD  and  is  an  input  to 
Task  302  -  Support  System  Alternatives. 

Subtask  301.2.6  -  Updates .  The  purpose  of  this  subtask  is  to  provide 
updates  of  the  functional  requirements  as  the  design  of  the  new 
system  progresses. 

Input . 

There  is  no  input,  as  such,  because  this  is  an  updating  action. 
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Output . 


Performance  of  this  subtask  continues  into  FSD.  The  results  of  this 
subtask  can  result  in  new  or  updates  to  existing  LSAR  B,  C,  D,  and  Dl 
sheets . 

b.  Task  302  -  Support  System  Alternatives 
Definition. 


Support  alternatives  for  a  new  system  addresses  each  element  of 
Integrated  Logistics  Support  (ILS),  and  must  satisfy  all  functional 
requirements  of  the  new  system.  These  alternatives  consider 
supportability,  cost,  and  readiness  drivers,  as  well  as,  the  unique 
functional  requirements  of  the  new  system.  Since  support  system 
concepts  can  vary  widely  in  terms  of  cost,  operational  availability, 
and  manpower  requirements;  it  is  the  purpose  of  this  task  to 
determine  the  which  support  system  alternative  is  best  for  the  new 
system.  To  accomplish  this  purpose,  this  task  consists  of  the 
following,  five  (5)  subtasks: 


o  Subtask  303.2.1 
o  Subtask  302.2.2 
o  Subtask  302.2.3 
o  Subtask  302.2.4 
o  Subtask  302.2.5 
Subtask  Procedures. 


Alternative  Support  Concepts 
Support  Concept  Uptates 
Alternative  Support  Plans 
Support  Plan  Updates 
Risks 


Subtask  302.2.1  -  Alternative  Support  Concepts.  The  performance  of 
this  subtask  identifies  alternative  support  concepts  which  sure  viable 
with  regard  to  the  individual  ILS  elements  and  to  the  design  and 
operational  concepts  proposed  for  the  new  system. 

Input. 

Input  to  this  subtask  is  obtained  from  Tasks  203  -  Comparative 
Analysis,  204  -  Technological  Opportunities,  205  -  Supportability  and 
Supportability  Related  Design  Factors,  and  301  -  Functional 
Requirements  Identification. 

Output . 

Performance  of  this  subtask  continues  into  and  is  completed  during 
DEM/VAL .  It  is  an  input  to  Task  303  -Evaluation  of  Alternatives  and 
Tradeoff  Analysis. 

Subtask  J02.2.2  -  Support  Concept  Updates.  The  purpose  of  this 
subtask  is  to  update  the  support  system  concept  as  a  result  of 
changes  in  imposed  constraints,  operational  scenarios,  etc.. 
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resulting  from  the  maturation  of  the  program. 

Input . 

Changes  in  the  designs,  contraints  and  support  concepts  as  the  new 
system  program  matures . 

Output . 

Performance  of  this  subtask  continues  into,  and  is  completed  in 
DEM/VAL.  It  is  an  input  to  Task  303  -  Evaluation  of  Alternatives  and 
Tradeoff  Analysis. 

Subtask  302.2.3  &  Subtask  302.2.4  -  These  subtasks  are  not  started 
until  FSO,  however,  some  selective  actions  may  be  undertaken  in 
preparation  for  performance  of  these  two  (2)  subtasks. 

Subtask  302.2.5  -  Risks.  The  purpose  of  this  subtask  is  to  evaluate 
the  risks  associated  with  the  alternative  support  concepts  identified 
in  Subtask  302.2.1. 

Input . 

There  is  no  input,  as  such,  for  this  subtask  as  it  is  an  effort  to 
evaluate  the  risks  involved  in  the  alternative  support  concepts. 

Output . 

Performance  of  the  subtask  is  continued  into  FSD.  It  is  an  input  to 
Task  303  -  Evaluation  of  Alternatives  and  Tradeoff  Analysis. 

c.  Task  303  -  Evaluation  of  Alternatives  and  Tradeoff  Analysis 

Definition. 

The  purpose  of  this  task  is  to  provide  quantitative  measures  of  the 
readiness,  supportability,  and  costs  of  various  design  and/or  support 
system  alternatives  for  the  new  system.  It  provides  the  basis  for 
selecting  the  support  concept  and  establishing  a  balance  among 
support,  performance  and  operational  considerations. 

This  task  includes  the  performance  of  the  following  ten  (10) 
subtasks : 

o  Subtask  303.2.1  -  Tradeoff  Criteria 
o  Subtask  303.2.2  -  Support  System  Tradeoffs 
o  Subtask  303.2.3  -  System  Tradeoffs 
o  Subtask  303.2.4  -  Sensitivities 

o  Subtask  303.2.5  -  Manpower  and  Personnel  Tradeoffs 
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o  Subtask 
o  Subtask 
o  Subtask 
o  Subtask 
o  Subtask 


303.2.6 

303.2.7 

303.2.8 

303.2.9 


-  Training  Tradeoffs 

-  Repair  Level  Analysis 

-  Diagnostic  Tradeoffs 

-  Comparative  Evaluations 


303.2.10  -  Energy  Tradeoffs 


Subtask  Procedures. 

Subtask  303.2.1  -  Tradeoff  Criteria.  The  purpose  of  this  subtask  is 
to  establish  the  criteria  for  performing  the  balance  of  the  subtasks 
in  this  task.  These  criteria,  are  developed  in  coordination  with  the 
Requiring  Authority  and  the  Design  and  Systems  Engineering 
communities . 

Input . 

Input  to  this  subtask  is  derived  from  Task  302  -  Support  System 
Alternatives  and  stantard  procedures /models ,  e.g.,  EDCAS,  Price 
(LCC). 

Output . 

Performance  of  this  subtask  continues  into  FSD  and  is  an  input  into 
the  balance  of  the  subtasks  in  this  task.  It  should  yield  the 
following  types  of  information  for  use  by  the  performing  activity  in 
its  accomplishment  of  the  other  subtasks: 

o  Review  and  approval  methods  and  procedures . 

o  Specific  evaluations,  tradeoffs,  and  analyses  to  be  performed. 

o  Specific  analytical  relationships,  techniques,  or  models  to  be 
used. 

o  Limiting  constraints  in  quantities  or  skills  of  operator  or  support 
personnel . 

o  Manpower  and  personnel  cost  factors  to  be  used  in  accomplishing 
evaluations,  analyses,  and  tradeoffs. 

Subtask  303.2.2  -  Support  System  Tradeoffs.  The  purpose  of  this 
subtask  is  to  determine  the  best  support  system  relative  to  those 
identified  through  Task  302  -  Support  System  Alternatives. 

Evaluations  and  tradeoffs  are  contucted  for  and  between  all  support 
systems  being  considered  for  the  C&TS  system. 

Input . 

Input  to  this  subtask  is  obtained  from  Task  302  -  Support  System 
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Alternatives  and  Subtask  303.2.1  -  Tradeoff  Criteria. 

Output . 

Performance  of  this  subtask  is  continued  into  PSD.  It  is  an  input  to 
Tasks  205  -  Supportability  and  Supportability  Related  Design  Factors, 
401  -  Task  Analysis,  and  40  2  -  Early  Fielding  Analysis. 

Subtask  303.2.3  -  System  Tradeoffs.  The  purpose  of  this  subtask  is  to 
recommend  system  alternative ( s )  based  on  cost,  schedule, operational 
availability,  performance,  and  supportability  factors.  This  is 
performed  by  the  Systems  Engineering  personnel  with  input  from 
logistics  specialist. 

Input . 

Input  to  this  task  is  derived  from  Task  205  -  Supportability  and 
Supportability  Related  Design  Factors  and  Task  302  -  Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  continues  into  FSD.  It  is  an  input  to 
Tasks  205  -  Supportability  and  Supportability  Related  Design  Factors, 
401  -  Task  Analysis,  and  402  -  Early  Fielding  Analysis. 

Subtask  303.2.4  -  Sensitivities.  The  purpose  of  this  subtask  is  to 
analyze  the  impact  variations  in  design  and  support  parameters  have 
on  system  availability.  Key  considerations  are  spares  budgets,  R&M 
factors,  support  and  test  equipment,  and  manpower  and  personnel 
skills  availability. 

Input . 

Input  to  this  task  is  Tasks  205  -  Supportability  and  Supportability 
Related  Design  Factors  and  302  -  Support* System  Alternatives. 

Output . 

Performance  of  this  subtask  continues  into  FSD.  It  is  an  input  to 
Tasks  401  -  Task  Analysis  and  402  -  Early  Fielding  Analysis. 

Subtask  303.2.5  -  Manpower  and  Personnel  Tradeoffs.  The  purpose  of 
this  subtask  is  to  analyze  the  alternative  support  system  concepts 
in  terms  of  the  number  of  personnel,  skill  levels,  specialty  codes, 
etc.,  associated  with  each. 

Input . 

Input  to  this  subtask  are  the  outputs  from  Tasks  205  -Supportability 
ant  Supportability  Related  Design  Factors,  302  -Support  System 
Alternatives,  and  any  known  manpower  and  personnel  constraints. 

Output . 


23 


The  performance  of  this  subtask  continues  into  FSO  Phase,  it  is  an 
input  to  Tasks  401  -  Task  Analysis  and  402  -  Early  Fielding  Analysis. 

Subtask  303.2.6  -  Training  Tradeoffs.  The  purpose  of  this  task  is  to 
evaluate  operational  concepts,  and  personnel  skill  level  requirements 
of  each  alternative  to  establish  the  optimum  training  program  to 
support  the  new  system's  operations  and  maintenance  requirements. 

Input . 

Input  to  this  subtaak  is  derived  from  Tasks  205  -  Supportability  and 
Supportability  Related  Design  Factors  and  302  -Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  continues  into  FSD.  It  is  an  input  to 
Tasks  401  -  Task  Analysis  and  402  -  Early  Fielding  Analysis. 

Subtask  303.2.7  -  Repair  Level  Analysis.  During  DEM/VAL  the  level  of 
repair  analysis  activities  are  primarily  used  as  a  design  tools  to 
establish  the  optimum  design  requirements  relative  to  logistic 
support.  The  C&TS  LSA  Program  employs  the  EDCAS  model  for  this 
purpose . 

The  EDCAS  Model  is  an  interactive  computer  program  for  estimating 
Life  Cycle  Cost  of  electronic  equipment  under  two  user  definable 
environments  called  El  and  E2.  EDCAS  consists  of  three  linked 
modules:  an  equipment  cost  model,  a  line  removable  unit  (LRU)  cost 
model  and  a  shop  removable  unit  (SRU)  cost  model.  EDCAS  can  be  used 
for  several  types  of  design/cost  tradeoff  analyses  including 
hardware /manpower  tradeoffs  and  preliminary  level  of  repair  analysis . 

Neither  EDCAS  nor  any  other  cost  model  attempts  to  find  ’‘optimal" 
values  for  design-descriptive  input  values.  Instead,  the  model 
computes  the  least  life  cycle  achievable,*  given  a  specific  design. 

The  major  part  of  the  software  surrounding  the  model  is  dedicated  to 
helping  the  engineer  find,  quickly  and  easily,  the  feasible 
combination  of  inputs  that  will  produce  the  lowest  life  cycle. 

Subtask  303.2.8  -  Diagnostic  Tradeoffs.  The  purpose  of  this  subtask 
is  to  analyze  alternative  diagnostic  concepts  such  as  Built-in  Test 
(BIT),  manual  testing,  automatic  testing,  etc.*  to  determine  the  best 
diagnostic  approach  for  each  alternative  under  consideration. 

Input . 

Input  to  this  subtask  is  dervied  from  Tasks  205  -  Supportability  and 
Supportability  Related  Design  Factors  and  302  -  Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  is  continued  into  and  completed  during 
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DEM/VAL.  It  is  an  input  to  Tasks  401  -  Task  Analysis  and  402  Early 
Fielding  Analysis. 

Subtask  303.2.9  -  Comparative  Evaluations.  The  purpose  of  this 
subtask  is  to  use  the  data  gained  as  a  result  of  other  Task  303 
efforts  to  update  the  comparative  analysis  performed  in  Task  203  - 
Comparative  Analysis. 

Input. 

Input  to  this  subtask  is  derived  from  other  parts  of  this  task  and 
Tasks  203  -  Comparative  Analysis  and  302  -  Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  is  continued  into  and  completed  during 
DEM/VAL.  It  is  an  input  back  into  Tasks  203  -  Comparative  Analysis 
and  Tasks,  401  -  Task  Analysis,  and  402  -Early  Fielding  Analysis. 

Subtask  303.2.10  -  Energy  Tradeoffs.  The  purpose  of  this  subtask  is 
to  conduct  tradeoffs  between  the  system  alternatives  proposed  and  the 
corresponding  Petroleum,  Oil,  and  Lubricants  (POL  )  requirements. 

Input . 

Input  to  this  subtask  is  derived  from  Tasks  203  -  Comparative 
Analysis  and  302  -  Support  System  Alternatives. 

Output . 

Performance  of  this  subtask  is  continued  into  and  completed  during 
DEM/VAL.  It  is  an  input  back  into  Task  203  -  Comparative  Analysis  and 
also  Tasks  401  -  Task  Analysis  and  402  -Early  Fielding  Analysis. 


4. 2. 3. 2  Demonstration  and  Validation 

a.  Task  301  -  Functional  Requirements  Identification 

Performance  of  this  task  during  DEM/VAL  consists  of  updating  and 
refining  Subtasks  301.2.1  -  Functional  Requirements,  301.2.2  -  Unique 
Functional  Requirements,  301.2.3  -  Risks,  301.2.4  Operations  and 
Maintenance  Tasks,  301.2.  -  Design  Alternatives  and  301.2.6  Updates. 

Subtask  Procedures 

Subtask  301.2.1  -  Functional  Requirements.  The  functions  which  must 
be  performed  to  operate  and  maintain  the  system,  and  to  return  it  to 
an  operational  condition  after  a  malfunction  which  were  identified 
during  the  CE  are  reviewed  and  updated  in  light  of  the  maturing 
design,  operational  scenario,  etc. 
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Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  updated 
Subtasks  203.2.1  -  Identify  Comparative  Systems,  203.2.2  -  Baseline 
Comparison  System,  and  Task  205  -  Support  Related  Design  Pactors  and 
other  Design  and  Systems  Engineering  information  (i.e.  PMEA/FMECA)  . 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  Some 
updating  may  be  required  during  PSD  to  accommodate  late  design 
changes . 

The  updated  and  refined  data  is  an  input  to  Subtask  301.2.2  -  Unique 
Functional  Requirements  and  Task  302  -  Support  System  Alternatives. 

Subtask  301.2.2  -  Unique  Functional  Requirements.  The  analysis  of 
those  unique  requirements  for  the  new  system  stemming  from  the  use  of 
new  technology  or  deployment  concepts,  as  well  as,  the  cost, 
operational  availability,  or  other  supportability  drivers  which  was 
performed  in  the  CE  is  updated  and  refined. 

Input . 

Input  to  this  subtask  is  derived  from  updated  Subtasks  203.2.1 
Identify  Comparative  Systems,  203.2.2  -  Baseline  Compariso  n  Systems, 
Task  205  -  Support  Related  Design  Factors,  and  Subtask  301.2.1  - 
Functional  Requirements. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  The 
updated  data  is  an  input  to  Subtask  301.2.3  -  Risks  Task  302  -Support 
System  Alternatives. 

Sub-task  301.2.3  -  Risks.  The  purpose  of  this  subtask  during  this 
phase  is  to  re-analyze  the  risks  associated  with  the  functions 
identified  in  updated  Subtasks  301.2.1  -  Functional  Requirements  and 
.301.2.2  -  Unique  Functional  Requirements. 

Input . 

Input  to  this  subtask  is  derived  frt.  .  updated  Subtasks  301.2.1 
Functional  Requirements  and  301.2.2  -  Unique  Functional  Requirements. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  The 
updated  data  is  an  input  to  Task  302  -  Support  System  Alternatives. 

Subtask  301.2.4  -  Operations  and  Maintenance  Tasks.  The  purpose  of 
this  subtask  during  this  phase  is  to  further  define  the  specific 
tasks  which  must  be  performed  in  carrying  out  the  functional 
requirements  identified  in  updated  Subtasks  301.2.1  -  Functional 
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Requirements  and  301.2.2  -  Unique  Functional  Requirements .  Failure 
Modes  and  Effects  Analysis  (FMEA)  is  updated  to  conform  to  the 
maturing  design  to  identify  the  Corrective  Maintenance  tasks. 
Additionally,  Reliability  Centered  Maintenance  (RCM)  analysis  is 
updated  to  identify  the  Preventative  Maintenance  tasks.  The  C&TS  LSA 
Program  is  using  the  McDonnell  Douglas  RCM  Logic  for  performance  of 
the  RCM  analysis. 

Input . 

Input  to  this  task  is  derived  from  updated  Subtasks  301.2.1 
Functional  Requirements  and  301.2.2  -  Unique  Functional  Requirements. 

Output . 

Performance  of  this  subtask  continues  into  FSD.  It  provides  data  for 
entry  into  LSAR  sheets  B,  Bl,  B2,  C,  D,  and  Dl,  and  is  an  input  to 
Tasks  302  -  Support  System  Alternatives,  and  401  -  Task  Analysis. 

Subtask  301.2.5  -  Design  Alternatives.  The  purpose  of  this  subtask 
during  this  phase  is  to  use  the  updated  functional  requirements 
identified  earlier  in  the  first  two  subtasks  as  a  basis  for  design 
feedback  to  correct  design  deficiencies. 

Input . 

Input  to  this  subtask  is  derived  from  the  preceding  updated  subtasks 
of  this  task. 

Output . 

Performance  of  this  subtask  continues  into  FSD  and  the  refined  data 
is  an  input  to  Task  302  -  Support  System  Alternatives. 

Subtask  301.2.6  -  Updates.  The  purpose  of  this  subtask  is  to  continue 
updates  of  the  functional  support  requirements  as  the  design  of  the 
new  system  progresses  and  to  begin  to  lay  out  the  basic  support 
system  design. 

Input . 

There  is  no  input,  as  such,  because  this  is  an  updating  action. 

Output . 

Performance  of  this  subtask  continues  into  FSD.  The  results  of  this 
subtask  can  result  in  new  LSAR  B,  Bl,  B2,  C,  D,  and  Dl  sheets.  The 
data  from  this  effort  is  an  input  to  Task  302  -  Support  System 
Alternatives . 

b.__  Task  302  -  Support  System  Alternatives 

Performance  of  this  task  during  DEM/VAL  consists  of  updating  and 
refining  Subtasks  302.2.1  -  Alternative  Support  Concepts,  302.2.2  - 


27 


Support  Concept  Updates,  and  302.2.5  -  Risks.  Subtasks  302.2.3  - 
Alternative  Support  Plans  and  302.2.4  -  Support  Plan  Updates  are  not 
performed  until  the  Full  Scale  Development  ( FSD)  Phase,  however,  some 
preliminary  work  on  these  two  (2)  subtasks  can  be  initiated  as  data 
develops.  A  typical  phasing  of  subtasks  during  DEM/VAL  is  depicted  in 
Figure  3.  Procedures  for  the  performance  of  each  DEM/VAL  Phase 
subtask  are  described  below. 

Subtask  Procedures. 

Subtask  302.2.1  -  Alternative  Support  Concepts.  The  performance  of 
this  subtask  updates  the  alternative  support  concepts  for  each  ILS 
element  identified  in  the  CE  effort. 

Input. 

Input  to  this  subtask  is  derived  from  updated  Tasks  203  Comparative 
Analysis,  204  -  Technological  Opportunities,  205  -Supportability  and 
Supportability  Related  Design  Factors,  and  301  -  Functional 
Requirements  Identification. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It 
serves  as  an  updated  input  to  Task  303  -  Evaluation  of  Alternatives 
and  Tradeoff  Analysis. 

Subtask  302.2.2  -  Support  Concept  Updates.  The  purpose  of  this 
subtask  is  to  update  the  support  system  concept  as  a  result  of 
changes  in  imposed  constraints ,  operational  scenarios ,  etc . , 
resulting  from  the  maturation  of  the  program. 

Input . 

Changes  in  the  support  concept  as  the  new  system  program  matures. 
Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It  is  an 
input  to  Task  303  -  Evaluation  of  Alternatives  and  Tradeoff  Analysis. 

Subtaak  302.2.3  and  302.2.4  -  Alternative  Support  Plans  and  Support 
Plan  Updates.  These  subtasks  are  not  started  until  the  FSD  Phase; 
however,  some  selective  actions  may  be  undertaken  in  preparation  for 
the  performance  of  these  two  (2)  subtasks. 

Subtask  302.2.5  -  Risks.  The  purpose  of  this  subtask  is  to  update  the 
evaluation  of  the  risks  associated  with  the  alternative  support 
concepts  identified  in  Subtask  302.2.1  during  the  CE. 

Input . 

Input  to  this  subtask  is  data  from  updated  Subtask  302.2.1  - 
Alternative  Support  Concepts. 
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Output . 


Performance  of  the  subtask  is  continued  into  the  FSD  Phase.  It  is  an 
updated  input  to  Task  303  -  Evaluation  of  Alternatives  and  Tradeoff 
Analysis . 

c.  Task  303  -  Evaluation  of  Alternatives  and  Tradeoff  Analysis 

Performance  of  this  task  during  DEM/VAL  consists  of  initiating 
Subtask  303.2.7  -  Repair  Level  Analysis,  and  updating  the  rest  of  the 
subtasks,  all  of  which  were  started  during  the  CE. 

Subtask  Procedures. 

Subtask  303.2.1  -  Tradeoff  Criteria.  The  purpose  of  this  subtask  to 
to  review  and  update  the  criteria  to  be  used  in  performing  the 
balance  of  the  subtasks  of  Task  303  which  were  previously  established 
during  CE. 

Input . 

Input  to  this  subtask  is  derived  from  Task  302  -  Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  continues  into  PSD  and  is  an  updated 
input  into  the  balance  of  the  subtasks  in  this  task. 

Subtask  303.2.2  -  Support  System  Tradeoffs.  The  purpose  of  this 
subtask  during  this  phase  is  to  confirm  or  update  the  best  support 
system  alternative  identified  from  those  established  by  Task  302  - 
Support  System  Alternatives.  Evaluations  and  tradeoffs  are  conducted 
for  and  between  all  support  systems  being  considered  for  the  new 
system. 

Input . 

Input  to  this  subtask  is  derived  from  updated  Task  302  -  Support 
System  Alternatives  and  Subtask  303.2.1  -  Tradeoff  Criteria. 

Output . 

Performance  of  this  subtask  is  continued  into  the  FSD  Phase.  It  is 
an  updated  input  to  Tasks  305  -  Supportability  Relate  d  Design 
Pactors,  401  -  Task  Analysis,  and  402  -  Early  Pielding  Analysis. 

Subtask  303.2.3  -  System  Tradeoffs.  The  purpose  of  this  subtask 
during  this  phase  is  to  update  the  recommended  system  alternative ( s ) 
based  on  cost,  schedule,  operational  availability,  performance,  and 
other  support ability  factors  which  were  identified  during  the  CE. 

This  is  normally  performed  by  the  Systems  Engineering  personnel  with 
input  from  logistics  representatives. 
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Input. 


Input  to  this  task  is  derived  from  updated  Tasks  205  -  Supportability 
and  Supportability  Related  Design  Factors  and  302  -  Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  continues  into  the  FSD  Phase.  It  is  an 
updated  input  to  Tasks  205  -  Supportability  and  Supportability 
Related  Design  Factors  and  the  initial  input  to  401  -  Task  Analysis. 

Subtask  303.2.4  -  Sensitivities.  The  purpose  of  this  subtask  during 
this  phase  is  to  update  the  impact  variations  in  design  and  support 
parameters  have  on  system  readiness  which  were  originally  analyzed 
during  the  CE.  Key  considerations  are  spares  budgets,  R&M  factors, 
and  manpower  and  personnel  skills  availability. 

Input. 

Input  to  this  task  is  derived  from  updated  Tasks  205  -  Supportability 
and  Supportability  Related  Design  Factors  and  302  -  Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  continues  into  FSD.  It  is  input  to  Task 
401  -  Task  Analysis. 

Subtask  303.2.5  -  Manpower  and  Personnel  Tradeoffs.  The  purpose  of 
this  subtask  during  this  phase  is  to  update  the  system  concept 
alternatives  in  terms  of  the  number  of  personnel,  skill  levels, 
specialty  codes,  etc.,  required  which  were  originally  analyzed  during 
the  CE. 

Input. 

Input  to  this  subtask  is  derived  from  updated  Tasks  205  - 
Supportability  and  Supportability  Related  Design  Factors,  302  - 
Support  System  Alternatives,  and  any  known  manpower  and  personnel 
constraints . 

Output . 

The  performance  of  this  subtask  continues  into  the  FSD  Phase.  It  is 
an  input  to  Tasks  401  -  Task  Analysis. 

Subtask  303.2.6  -  Training  Tradeoffs.  The  purpose  of  this  subtask 
during  this  phase  is  to  update  analyses  and  tradeoffs  among  design, 
operational  concepts,  and  personnel  skill  level  requirements  which 
were  conducted  during  the  CE  to  achieve  a  viable  training  program  to 
support  the  new  system's  operations  and  maintenance  requirements. 

Input . 
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Input  to  this  subtask  is  derived  from  updated  Tasks  205  - 
Supportability  and  Supportability  Related  Design  Factors  and  302  - 
Support  System  Alternatives . 

Output . 

Performance  of  this  subtask  continues  into  the  FSD  Phase.  It  is  an 
input  to  Tasks  401  -  Task  Analysis. 

Subtask  303.2.7  -  Repair  Level  Analysis.  This  subtask  is  initiated 
during  this  phase  and  its  purpose  is  to  perform  the  traditional  level 
of  repair  analysis  commensurate  with  the  level  of  design,  operation, 
and  support  data  available  at  this  time . 

Input . 

Input  to  this  subtask  is  derived  from  Task  302  -  Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  continues  into  the  FSD  Phase.  It  is  an 
input  to  Task  401  -  Task  Analysis. 

Subtask  303.2.8  -  Diagnostic  Tradeoffs.  The  purpose  of  this  subtask 
during  this  phase  is  to  update  and  complete  the  alternative 
diagnostic  concepts  such  as  Built-in  Test  (BIT),  manual  testing, 
automatic  testing,  etc.,  which  were  initially  analyzed  during  the 
CE  to  determine  the  best  diagnostic  approach  for  each  alternative 
under  consideration. 

Input. 

Input  to  this  subtask  is  derived  from  updated  Tasks  205  - 
Supportability  and  Supportability  Related  Design  Factors  and  302  - 
Support  System  Alternatives . 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It  is  an 
input  to  Tasks  401  -  Task  Analysis. 

Snfrfawlc  303.2.9  -  Comparative  Evaluations.  The  purpose  of  this 
subtask  during  this  phase  is  to  update  and  complete  the  comparative 
evaluations  using  the  data  gained  as  a  result  of  other  Task  303 
efforts  to  update  the  comparative  analysis  performed  in  Task  203  - 
Comparative  Analysis. 

Input . 

Input  to  this  subtask  is  derived  from  other  updated  parts  of  this 
task  and  Tasks  203  -  Comparative  Analysis  and  302  -  Support  System 
Alternatives . 
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Output . 


Performance  of  this  subtask  is  completed,  during  this  phase,  it  is  an 
input  back  into  Task  203  -  Comparative  Analysis,  and  Tasks  401  Task 
Analysis.  , 

Subtask  303 .2.10  -  Energy  Tradeoffs.  The  purpose  of  this  subtask 
during  this  phase  is  to  update  and  complete  tradeoffs  between  the 
proposed  system  alternatives  and  the  corresponding  Petroleum,  Oil, 
and  Lubricants  (POL)  requirements  conducted  during  the  CE.  Some 
selective  updating  could  be  required  for  this  subtask  during  the  FSD 
Phase  to  accommodate  late  design  or  operational  changes. 

Input . 

Input  to  this  subtask  is  derived  from  updated  Tasks  203  Comparative 
Analysis  and  302  -  Support  System  Alternatives. 

Output . 

Performance  of  this  subtask  is  essentially  completed  during  this 
phase.  It  is  an  input  back  into  Task  203  -  Comparative  Analysis  and 
also  Tasks  401  -  Task  Analysis. 


4 . 2 . 3 . 3  Full  Scale  Development 

a.  Task  301  -  Functional  Requirements  Identification 

Performance  of  this  task  during  FSD  Phase  consists  of  updating, 
refining,  and  completing  Subtasks  301.2.4  -  Operations  and 
Maintenance  Tasks,  301.2.5  -  Design  Alternatives,  and  301.2.6  - 
Updates.  The  first  three  subtasks  were  completed  during  DEM/VAL. 

They  may,  however,  require  some  minor  update  during  FSD. 

Subtask  Procedures . 

Subtask  301.2.4  -  Operations  and  Maintenance  Tasks.  The  purpose  of 
this  subtask  during  this  phase  is  to  further  define  the  specific 
tasks  which  must  be  performed  in  carrying  out  the  functional 
requirements  identified  in  the  latest  updated  Subtasks  301.2.1  - 
Functional  Requirements  and  301.2.2  Unique  Functional  Requirements. 
Failure  Modes  and  Effects  and  Criticality  Analysis  ( FMEACA) 
information  is  further  updated  to  conform  to  the  maturing  design  to 
identify  the  Corrective  Maintenance  tasks.  Additionally,  Reliability 
Centered  Maintenance  (RCM)  analysis  is  further  updated  to  identify 
the  Preventive  Maintenance  tasks. 

Input . 

Input  to  this  task  is  derived  from  the  latest  updated  Subtasks 
301.2.1  -  Functional  Requirements  and  301.2.2  -  Unique  Functional 
Requirements . 

Output. 
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Performance  of  this  subtask  is  completed  during  this  phase,  it 
provides  updated  data  for  entry  into  LSAR  Records  Bf  Bl,  B2,  C,  D, 
and  Dl,  and  is  an  input  to  Tasks  302  -  Support  System  Alternatives, 
and  401  -  Task  Analysis. 

Subtask  301.2.5  -  Design  Alternatives.  The  purpose  of  this  subtask 
update  the  functional  requirements  identified  earlier  in  the  first 
two  subtasks  as  a  basis  for  design  feedback  to  correct  design 
deficiencies. 

Input. 

Input  to  this  subtask  is  derived  from  the  preceding  updated  subtasks 
of  this  task. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase  and  the 
refined  data  is  an  input  to  Task  302  -  Support  System  Alternatives . 

Subtask  301.2.6  -  Updates.  The  purpose  of  this  subtask  is  to  continue 
updates  of  the  functional  requirements  as  the  design  of  the  new 
system  become  fixed  during  this  phase. 

Input. 

There  is  no  input,  as  such,  because  this  is  an  updating  action. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  The 
results  of  this  subtask  can  result  in  new  LSAR  B,  C,  D,  and  Dl 
Records.  The  updated  data  from  this  effort  is  an  input  to  Task  302  - 
Support  System  Alternatives . 

b.  Task  302  -  Support  System  Alternatives 

Performance  of  this  subtask  during  FSD  consists  of  updating, 
refining,  and  completing  Subtasks  302.2.5  -  Risks,  which  was  started 
during  the  Concept  Phase  and  updated  during  DEM/VAL.  Additionally, 
Subtasks  302.2.3  -  Alternative  Support  Plans  and  302.2.4  -  Support 
Plan  Updates  are  initiated  and  completed  during  this  phase.  Subtasks 
302.2.1  -  Alternative  Support  Concepts  and  302.2.2  Support  Concept 
Updates  were  completed  during  the  previous  DEM/VAL  efforts. 

Subtask  Procedures. 

Subtask  302.2.3  -  Alternative  Support  Plans.  The  purpose  of  this 
subtask  is  to  develop  and  document  alternative  support  plans  for  the 
new  system. 

Input . 

Input  to  this  subtask  is  derived  from  Tasks  205  -  Supportability 
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Related  Design  Factors,  301  -  Functional  Requirements  Identification 
and  the  results  of  401,  Task  Analysis. 

Output . 

Performance  of  this  suhtask  is  completed  during  this  phase.  It  is  an 
input  to  Tasks  303  -  Evaluation  of  Alternatives  and  Tradeoffs 
Analysis  and  401  -  Task  Analysis. 

Subtask  302.2.4  -  Support  Plan  Updates.  The  purpose  of  this  subtask 
is  to  update  and  refine  the  alternative  support  plans  as  tradeoffs 
are  conducted  and  the  new  system's  design  and  operational  scenario 
become  better  defined. 

Input . 

Input  to  this  subtask  is  derived  from  Tasks  205  -  Supportability  and 
Supportability  Related  Design  Factors  and  301  -  Functional 
Requirements  Identification. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It  is  an 
input  to  Tasks  303  -  Evaluation  of  Alternative  and  Tradeoff  Analysis 
and  401  -  Task  Analysis. 

Subtask  302.2.5  -  Risks.  The  purpose  of  this  subtask  during  this 
phase  is  to  further  update  and  complete  the  evaluation  of  risks 
associated  with  the  alternative  support  concepts  identified  in 
Subtask  302.2.1  -  Alternative  Support  Concepts  during  the  Concept 
Phase  and  updated  during  DEH/VAL. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It  is  an 
input  to  Tasks  303  -  Evaluation  of  Alternatives  and  Tradeoff  Analysis 
and  401  -  Task  Analysis. 

c.  Task  303  -  Evaluation  of  Alternatives  and  Tradeoff  Analysis. 

Performance  of  this  task  during  FSD  consists  of  updating  and/or 
completing  all  of  the  subtasks  except  Subtasks  303.2.8  -  Diagnostic 
Tradeoffs,  303.2.9  -Comparative  Evaluations  and  303.2.10  -  Energy 
Tradeoffs  which  were  completed  during  DEM/VAL. 

Subtask  Frocedur&s. 

Subtask  303.2.1  -  Tradeoff  Criteria.  The  purpose  of  this  subtask 
during  this  phase  is  to  update,  refine,  and  complete  the  criteria  for 
performing  the  balance  of  the  subtasks  in  this  task  which  were 
est<iblished  durinc  the  CE  and  updated  during  DEM/VAL. 

Input . 

Input  to  this  task  is  derived  from  Task  302  -  Support  System 
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Alternatives . 


Output . 

Performance  of  this  subtask  is  completed  during  this  phase  and  is  an 
updated  input  into  the  balance  of  the  subtasks  in  this  task. 

Subtask  303.2.2  -  Support  System  Tradeoffs.  The  purpose  of  this 
subtask  during  this  phase  is  to  update,  refine,  and  complete  the  best 
support  system  determined  during  the  CE  and  updated  during  DEM/VAL 
for  each  new  system  alternative  support  system  identified  in  Task  302 
Support  System  Alternatives.  Evaluations  and  tradeoffs  are  conducted 
for  and  between  all  support  systems  being  considered  for  the  new 
weapon  system. 

Input . 

Input  to  this  subtask  is  derived  from  the  latest  updated  Task  302  - 
Support  System  Alternatives  and  Subtask  303.2.1  -  Tradeoff  Criteria. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It  is  an 
updated  input  to  Tasks  305  -  Supportability  and  Supportability 
Related  Design  Factors,  401  -  Task  Analysis,  and  402  -  Early  Fielding 
Analysis . 

Subtask  303.2.3  -  System  Tradeoffs.  The  purpose  of  this  subtask 
during  this  phase  is  to  update,  refine,  and  complete  the  recommended 
system  alternative(s)  based  on  cost,  schedule,  operational 
availability,  performance,  and  supportability  factors  which  were 
identified  during  the  CE  and  updated  during  DEM/VAL.  This  subtask  is 
normally  performed  by  the  Systems  Engineering  personnel  with  input 
from  logistics  representatives. 

Input . 

Input  to  this  task  is  derived  from  updated  Tasks  205  -  Supportability 
and  Supportability  Related  Design  Factors  and  302  -  Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It  is  an 
updated  input  to  Tasks  205  -  Support ability  and  Supportability 
Related  Design  Factors,  401  -  Task  Analysis,  and  402  -  Early  Fielding 
Analysis . 

Subtask  303.2.4  -  Sensitivities.  The  purpose  of  this  subtask  during 
this  phase  is  to  update,  refine,  and  complete  the  impact  variations 
in  design  and  support  parameters  have  on  system  operational 
availibility  which  were  originally  analyzed  during  the  CE  and  updated 
during  DEM/VAL.  Key  considerations  are  spares  budgets,  R&M  factors, 
and  manpower  and  personnel  skills  availability. 
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Input . 


Input  to  this  task  is  derived  from  updated  Tasks  205  -  Supportability 
and  Supportability  Related  Design  Factors  and  302  -  Support  System 
Alternatives . 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It  is  an 
updated  input  to  Tasks  401  -  Task  Analysis  and  402  -  Early  Fielding 
Analysis. 

Subtask  303.2.5  -  Manpower  and  Personnel  Tradeoffs.  The  purpose  of 
this  subtask  during  this  phase  is  to  update,  refine,  and  complete  the 
system  concept  alternatives  in  terms  of  the  number  of  personnel, 
skill  levels,  specialty  codes,  etc.,  required  which  were  originally 
analyzed  during  CE  and  updated  during  DEM/VAL. 

Input. 

Input  to  this  subtask  is  derived  from  updated  Tasks  205  - 
Supportability  and  Supportability  Related  Design  Factors,  302  - 
Support  System  Alternatives,  and  any  known  manpower  and  personnel 
constraints . 

Output . 

The  performance  of  this  subtask  is  completed  during  this  phase.  It 
is  an  updated  input  to  Tasks  401  -  Task  Analysis  and  402  -  Early 
Fielding  Analysis. 

Subtask  303.2.6  -  Training  Tradeoffs.  The  purpose  of  this  subtask 
during  this  phase  is  to  complete  the  analyses  and  tradeoffs  among 
design,  operational  concepts,  and  personnel  skill  level  requirements 
which  were  conducted  during  the  Concept  Phase  and  updated  during 
DEM/VAL  to  achieve  a  viable  training  program  to  support  the  new 
system's  operations  and  maintenance  requirements. 

Input . 

Input  to  this  subtask  is  derived  from  updated  Tasks  205  - 
Supportability  and  Supportability  Related  Design  Factors  and  302  - 
Support  System  Alternatives. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It  is  an 
updated  input  to  Tasks  401  -  Task  Analysis  and  402  -  Early  Fielding 
Analysis . 

Subtask  303.2.7  -  Repair  Level  Analysis.  The  purpose  of  this  subtask 
during  this  phase  is  to  reiterate  the  level  of  repair  analysis 
activities  conducted  during  previous  the  phases.  During  this  phase 
the  purpose  is  to  establish  quantitative  levels  for  spare  and  repair 
parts  and  for  tools,  test  equipments  and  other  support  items. 
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Further  the  RLA  is  used  to  confirm  projected  system  operational 
availability  and  life  cycle  cost  estimates  in  order  to  establish 
necessary  budgets . 

Input . 

Input  to  this  subtask  is  derived  from  updated  Task  302  -  Support 
System  Alternatives . 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  It  is  an 
updated  input  to  Task  401  -  Task  Analysis  and  402  -  Early  Fielding 
Analysis. 

Subtask  303.2.8  -  Diagnostic  Tradeoffs.  This  subtask  was  completed 
during  DEM/VAL.  It  is  reiterated  only  in  the  event  of  design  changes 
which  may  impact  previous  diagnostic  capability  projections. 

Subtask  303.2.9  -  Comparative  Evaluations.  This  subtask  was  completed 
during  DEM/VAL. 

Subtask  303.2.10  -  Energy  Tradeoffs.  This  subtask  was  completed 
during  DEM/VAL;  however,  some  selective  updating  may  be  required 
during  this  phase  to  accommodate  late  design  or  operational  changes 
in  the  program. 


4. 2. 3. 4  Production  and  Deployment 

4.2.4  Task  Section  400,  Determination  of  Logistic  Support  Resource 
Requirements 

4 . 2 . 4 . 1  Concept  Exploration 

Task  Section  400  is  not  employed  during  the  CE  phase  due  the  high 
degree  of  instability  of  the  design.  Detailed  support  information  to 
be  used  to  assist  in  the  development  of  conceptual  designs  are 
obtained  through  the  use  of  historical  information  from  similar 
systems  through  the  Comparative  Analysis  (Task  203). 


4. 2. 4. 2  Demonstration  and  Validation 

3L _ Tflak  4jLU_Tqgfr  Analysis 

Performance  of  this  task  during  DEM/VAL  consists  of  performing 
Subtasks  401.2.1  -  Task  Analysis,  401.2.2  -  Analysis  Documentation, 

401.2.3  -New/Critical  Support  Resources,  401.2.4  -  Training 
Requirements  and  Recommendations ,  401.2.5  -  Design  Improvements, 
401.2.6  Management  Plans ,  401.2.8  -  Provisioning  Requirements , 

401.2.9  -  Validation,  and  401.2.11  -LSAR  Updates.  Subtask  401.2.7 
-Transportability  Analysis  was  performed  during  CE  and  updated  during 
DEM/VAL. 
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Performance  of  this  task  requires  the  utmost  in  coordination  and 
interfacing  because  it  involves  essentially  every  system  engineering 
discipline  and  ILS  functional  element  manager.  During  DEM/VAL  the 
key  is  not  to  implement  the  Task  Analysis  for  those  portions  of  the 
design  that  are  highly  unstable.  The  communities  involved  in  the 
Task  Analysis  must  include  Design,  reliability,  maintainability, 
safety,  etc. 

Subtask  Procedures. 

Subtask  401.2. 1  -  Task  Analysis.  The  purpose  of  this  subtask  is  to 
analyze  each  operations  and  maintenance  task  previously  identified  by 
Task  301  -  Functional  Requirements  Identification.  The  analyses 
should  be  completed  to  the  lowest  reparable  assembly  level  as  soon  as 
the  initial  design  is  established. 

Input. 

During  this  phase,  input  to  this  subtask  is  derived  from  Subtasks 
301.2.4  -  Operations  and  Maintenance  Tasks  and  303.2.2  -  Support 
System  Trade-offs. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  Some 
updating  may  be  required  during  Production  to  accommodate  engineering 
change  activity.  Data  from  this  subtask  is  documented  in  the  LSAR  on 
the  C,  D,  D,  and  D1  Records.  Hew  or  peculiar  support  resource 
requirements  are  captured  on  the  LSAR  E ,  F ,  and  G  Records .  The 
LSAR  serves  as  the  primary  input  to  Task  501  -Supportability  Test, 
Evaluation,  and  Verification. 

Subtask  401.2.2  -  Analysis  Documentation.  This  subtask,  along  with 
Subtask  401.2.1  -  Task  Analysis  discussed  above,  are  the  basic 
subtasks  of  Task  401.  Both  are  performed  to  the  lowest  reparable 
assembly  level  as  soon  as  the  initial  designs  are  established.  The 
purpose  of  this  subtask  is  to  document  the  results  of  subtask  401.2.1 
-  Task  Analysis. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Subtask 
401.2.1  -  Task  Analysis. 

Output . 

Performance  of  this  subtask  is  initiated  during  this  phase  for  those 
portions  of  the  design  which  are  stable  and  will  be  updated  during 
the  PSD  Phase.  Data  from  this  subtask,  along  with  data  from  Subtask 
401.2.1  -  Task  Analysis  is  documented  in  the  LSAR  C,  D,  and  D1 
Records.  New  or  peculiar  support  resources  are  flagged  using  the 
LSAR  E,  F  and  G  Records.  The  results  will  be  used  to  support  the 
demonstations  conducted  under  Task  501  —Supportability  Test, 
Evaluation,  and  Verification. 
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Subtask  401.2.3  -  New/Critical  Support  Resources.  The  purpose  of  this 
subtask  is  to  identify  resources  which  will  require  either  new 
development  or  special  attention  to  manage  scarce  resources. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Subtask 
303.2.2  -  Support  System  Tradeoffs. 

Output . 

Performance  of  this  subtask  is  initiated  during  this  phase  and 
updated  FSD.  Further  updating  will  be  required  during  the  Production 
Phase  to  accommodate  later  design  changes.  The  support  resources  are 
documented  in  the  LSAR  E,  El,  E2,  F,  and  G  Records.  The  Task  results 
provide  input  to  Subtask  401.2.6  -  Management  Plans;  and  Tasks  402 
-Early  Fielding  Analysis  and  501  -  Supportability  Test,  Evaluation, 
and  Verification. 

Subtask  401.2.4  -  Training  Requirements  and  Recommendations .  The 
purpose  of  this  subtask  is  to  identify  training  requirements  and  a 
method  for  providing  the  training.  It  must  consider  the  task 
procedures,  and  manning  and  skill  levels  required  to  support  the  new 
system  and  equipment. 

Input . 

During  this  phase,  input  to  this  task  is  derived  from  Subtasks 
401.2.1  -  Task  Analysis  and  401.2.2  -  Analysis  Documentation. 

Output . 

The  results  of  this  subtask  are  documented  in  the  LSAR  D1  and  G 
Records.  It  feeds  Subtasks  402  -  Early  Fielding  Analysis  and  501  - 
Supportability  Test,  Evaluation,  and  Verification. 

Subtask  401.2.5  -  Design  Improvements.  The  purpose  of  this  subtask 
is  to  determine  which  operations  and/or  maintenance  tasks  fail  to 
meet  established  goals.  It  should  be  performed  by  both  the  Performing 
Activity  and  the  Requiring  Authority  because  it  verifies  the 
supportability  and  supportability-related  design  goals  previously 
established  by  Task  205  -  Supportability  Related  Design  Factors. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Task  205  - 
Supportability  Related  Design  Factors. 

Output . 

Subtask  results  are  documented  on  the  LSAR  D1  and  G  Records.  It 
feeds  Task  303  -Evaluation  of  Alternatives  and  Tradeoff  Analysis. 

Subtask  401.2.6  -  Management  Plans.  The  purpose  of  this  subtask  is  to 
identify  any  action  which  might  be  taken  to  lessen  the  risks 
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associated  with  new  or  critical  logistics  resources. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Subtask 
401.2.3  -  New/Critical  Support  Resources. 

Output . 

This  subtask  provides  input  to  Task  303  -Evaluation  of  Alternatives 
and  Tradeoff  Analysis. 

Subtask  401.2.7  -  Transportability  Analysis.  This  subtask  was 
initiated  during  CE  and  is  continually  updated  based  upon  the 
evolving  system  design. 

Subtask  401.2.8  -  Provisioning  Requirements.  The  purpose  of  this 
subtask  is  to  capture  the  initial  provisioning  information  relative 
to  the  hardware  design. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  the 
engineering  drawings,  R&M  characteristics,  and  the  individual 
Logistics  Element  specialists  from  areas  such  as  packaging, 
cataloging  and  technical  publications. 

Output . 

This  subtask  is  used  to  build  the  LSAR  H  and  HI  Records  to  support 
initial  spares  projections  and  provisioning  budget  estimates. 

Subtask  401.2.9  -  Validation.  The  purpose  of  this  subtask  is  to 
validate  the  LSAR  documentation.  Validation  is  accomplished  through 
a  combination  of  on-going  internal  review,  by  the  Performing  activity, 
periodic  review  by  the  Requiring  Authority  and  through  feedback  of 
the  testing  and  demonstration  efforts.  Where  possible,  the  LSAR 
information  should  be  made  available  to  the  Requiring  Authority 
reviewing  activities  via  a  remote  access  capability  to  minimize  time 
spent  on-site  and  to  ensure  that  they  always  have  access  to  the  most 
current  information  to  support  their  in-house  activities. 

Input . 

During  this  phase,  there  is  no  input  as  such  because  the  purpose  of 
this  subtask  is  to  confirm  the  validity  of  the  LSAR  data  base. 

Output . 

Updates  to  the  LSAR  Data  Records  will  be  generated  based  upon 
testing,  demonstrations  and  internal  and  formal  reviews. 

Subtask  401.2.11  -  LSAR  Updates.  The  development  of  the  LSAR  is  an 
ongoing  effort,  becoming  more  complete  and  detailed  as  the  new  system 
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and  support  system  designs  evolve  and  mature.  It  is,  however, 
necessary  to  use  the  LSAR  data  as  it  evolves.  This,  in  turn,  requires 
updating  the  data  as  the  LSA  process  continues  to  ensure  the  latest 
information  is  available  to  all  ILS  element  managers  and  decision 
makers . 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  the 
iterative  nature  of  the  LSA  process.  For  example,  as  new  LSA  data  is 
developed  due  to  evolving  design  of  the  new  system,  the  LSAR  must  be 
updated  to  reflect  the  latest  status  of  the  particular  ILS  element 
analysis . 

Output . 

LSAR  updates  based  upon  identified  change  requirements. 

4. 2. 4. 3  Full  Scale  Development 
a.  Task  401.  Task  Analysis 

Performance  of  this  task  during  FSD  consists  of  performing  Subtasks 
401.2.1  -  Task  Analysis,  401.2.2  -  Analysis  Documentation,  401.2.3  - 
New/ Critical  Support  Resources,  401.2.4  -  Training  Requirements  and 
Recommendations,  401.2.5  -  Design  Improvements,  401.2.6  Management 
Plans,  401.2.8  -Provisioning  Requirements,  401.2.9  -  Validation, 
401.2.10  -  ILS  Output  Products,  and  401.2.11  -  LSAR  Updates.  Subtask 
401.2.7  -Transportability  Analysis  was  performed  during  CE. 
Performance  of  this  task  requires  the  utmost  in  coordination  and 
interfacing  because  it  involves  essentially  every  system  engineering 
discipline  and  ILS  functional  element  manager.  Design,  reliability, 
maintainability,  safety,  etc.  are  all  involved  in  satisfying  the 
requirements  of  this  task. 

Subtask  Procedures . 

Subtask  401.2.1  -  Task  Analysis.  The  purpose  of  this  subtask  is  to 
analyze  each  operations  and  maintenance  task  previously  identified  by 
Task  301  -  Functional  Requirements  Identification.  The  analyses 
should  be  completed  to  the  lowest  reparable  assembly  level  as  soon  as 
the  initial  design  is  established. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Subtasks 
301.2.4  -  Operations  and  Maintenance  Tasks  and  303.2.2  -  Support 
System  Trade-offs. 

Output . 

Some  updating  may  be  required  during  Production  to  accommodate 
engineering  change  activity.  Data  from  this  subtask  is  documented  in 
the  LSAR  on  the  C,  D,  D,  and  D1  Records.  New  or  peculiar  support 
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resource  requirements  are  captured  on  the  LSAR  E,  F,  and  G  Records. 
The  completed  LSAR  defines  the  support  system  as  designed  and  serves 
as  the  primary  input  to  Task  402  -Early  Fielding  Analysis  and  Task 
501  -Supportability  Test,  Evaluation,  and  Verification. 

Subtask  401.2.2  -  Analysis  Documentation.  This  subtask,  along  with 
Subtask  401.2.1  -  Task  Analysis  discussed  above,  are  the  basic 
subtasks  of  Task  401.  Both  are  performed  to  the  lowest  reparable 
assembly  level  as  soon  as  the  initial  design  is  established.  The 
purpose  of  this  subtask  is  to  document  the  results  of  subtask  401.2.1 
-  Task  Analysis. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Subtask 
401.2.1  -  Task  Analysis. 

Output . 

Updates  will  be  required  during  Production  to  capture  changes 
resulting  from  design  change  activity.  Data  from  this  subtask,  along 
with  data  from  Subtask  401.2.1  -  Task  Analysis  is  documented  in  the 
LSAR  C,  D,  and  D1  Records.  New  or  peculiar  support  resources  are 
flagged  using  the  LSAR  E,  F  and  G  Records,  and  is  an  input  to  Tasks 
402  -  Early  Fielding  Analysis  and  501  -  Supportability  Test, 
Evaluation,  and  Verification. 

Subtask  401.2.3  -  New/ Critical  Support  Resources.  The  purpose  of  this 
subtask  is  to  identify  resources  which  will  require  either  new 
development  or  special  attention  to  manage  scarce  resources. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Subtask 
303.2.2  -  Support  System  Tradeoffs. 

Output . 

Some  updating  may  be  required  during  the  Production  Phase  to 
accommodate  late  design  changes .  These  resources  are  documented  in 
the  LSAR  E,  El,  E2,  F,  and  G  Records.  It  provides  input  to  Subtask 
401.2.6  -  Management  Plans;  and  Tasks  402  -  Early  Fielding  Analysis 
and  501  -  Supportability  Test,  Evaluation,  and  Verification. 

Subtask  401.2.4  -  Training  Requirements  and  Recommendations.  The 
purpose  of  this  subtask  is  to  identify  training  requirements  and  a 
method  for  providing  the  training.  It  must  consider  the  task 
procedures,  and  manning  and  skill  levels  required  to  support  the  new 
system  and  equipment. 

Input . 

During  this  phase,  input  to  this  task  is  derived  from  Subtasks 
401.2.1  -  Task  Analysis  and  401.2.2  -  Analysis  Documentation. 
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Output . 


Some  updating  may  be  required  during  the  Production  Phase  to 
accommodate  engineering  changes .  This  data  is  documented  in  the  LSAR 
D1  and  G  Records.  It  feeds  Subtasks  402  -  Early  Fielding  Analysis  and 
501  -  Supportability  Test,  Evaluation,  and  Verification. 

Subtask  401.2.5  -  Design  Improvements.  The  purpose  of  this  subtask 
is  to  determine  which  operations  and/or  maintenance  tasks  fail  to 
meet  established  goals .  It  should  be  performed  by  both  the  Navy  and 
the  contractor  because  it  verifies  the  supportability  and 
supportability  related  design  goals  previously  established  by  Task 
205  -  Supportability  Related  Design  Factors. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Task  205  - 
Supportability  Related  Design  Factors. 

Output . 

Some  updating  may  be  required  during  the  Production  Phase  to 
accommodate  late  design  changes.  This  data  is  documented  in  the  LSAR 
D1  and  G  Records.  It  feeds  Task  303  -  Evaluation  of  Alternatives  and 
Tradeoff  Analysis. 

Subtask  401.2.6  -  Management  Plans.  The  purpose  of  this  subtask  is  to 
identify  any  action  which  might  be  taken  to  lessen  the  risks 
associated  with  new  or  critical  logistics  resources. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  Subtask 
401.2.3  -  New/Critical  Support  Resources. 

Output . 

Initial  performance  of  this  subtask  is  completed  during  this  FSD 
Phase.  Some  updating  may  be  required  during  the  Production  Phase  to 
accommodate  design  changes.  This  subtask  provides  input  to  Task  303  - 
Evaluation  of  Alternatives  and  Tradeoff  Analysis. 

Subtask  401.2.7  -  Transportability  Analysis.  This  subtask  was 
completed  during  the  Demonstration  and  Validation  Phase.  Additional 
effort  on  this  subtask  during  this  phase  requires  considerable 
interpretation  of  intent  to  be  cost  effective. 

Subtask  401.2.8  -  Provisioning  Requirements.  The  purpose  of  this 
subtask  is  to  satisfy  the  requirement  of  DoD  Instruction  4151.7 
entitled  "Uniform  Technical  Documentation  for  Use  in  Provisioning  of 
End  Items  of  Material.”  This  instruction  states  that  all  provisioning 
will  be  accomplished  using  the  LSAR.  **NOTE**  There  is  still  some 
question  as  to  how  the  provisioning  information  is  to  be  delivered. 
Final  procedures  for  Provisioning  Technical  Documentation  (PTD) 
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delivery  will  be  established  upon  receipt  of  guidance  from  McDonnell 
Douglas . 

Input . 

During  this  phase ,  input  to  this  subtask  is  derived  from  the 
engineering  drawings,  R&M  characteristics,  and  the  individual 
Logistics  Element  specialists  from  areas  such  as  packaging,  pricing 
cataloging  and  technical  publications . 

Output . 

Initial  performance  of  this  task  is  completed  during  this  phase. 
Update  will  undoubtedly  be  required  during  the  Production  Phase  to 
accommodate  Design  Change  Notice  (DCN)  activity.  This  subtask 
provides  all  of  the  technical  information,  less  the  engineering 
drawings,  to  satisfy  the  PTD  delivery  requirements.  This  information 
forms  the  basis  for  spares  procurement  during  production  and  is  an 
input  to  Tasks  402  -Early  Fielding  Analysis  and  501  Supportability 
Test,  Evaluation,  and  Verification. 


Subtask  401.2.9  -  Validation.  The  purpose  of  this  subtask  is  to 
validate  the  LSAR  documentation.  Validation  is  accomplished  through 
a  combination  of  on-going  internal  review  by  the  Performing  activity, 
periodic  review  by  the  Requiring  Authority  and  through  feedback  of 
the  testing  and  demonstration  efforts.  Where  possible,  the  LSAR 
information  should  be  made  available  to  the  Requiring  Authority 
reviewing  activities  via  a  remote  access  capability  to  minimize  time 
spent  on-site  and  to  ensure  that  they  always  have  access  to  the  most 
current  information  to  support  their  in-house  activities. 

Input . 

During  this  phase,  there  is  no  input  as  such  because  the  purpose  of 
this  subtask  is  to  confirm  the  validity  of  the  LSAR  data  base. 

Output . 

Performance  of  this  subtask  is  complted  during  this  phase.  Update 
will  be  required  during  the  Production  Phase  to  accommodate  design 
changes.  The  result  of  this  subtask  is  confirmation  of  the  validity 
of  the  LSAR  data  base  and  the  indirect  validation  of  the  technical 
products  developed  form  the  LSAR  source  information. 

Subtask  401.2.10  -  ILS  Output  Products.  The  product  of  this  subtask 
is  the  LSAR  output  reports  based  upon  the  developing  LSAR  data  base. 
These  LSA  reports  or  source  information  should  be  coordinated  among 
all  ILS  element  managers  to  ensure  that  the  ILS  program  for  the  new 
system  are  developed  in  an  orderly,  timely  and  consistent  manner. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  the  LSAR. 
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Output . 


Performance  of  this  subtask  is  completed  during  this  phase.  Update 
will  be  required  during  the  Production  Phase  to  accommodate  design 
changes.  Data  from  this  subtask  is  an  input  to  Tasks  402  -  Early 
Fielding  Analysis  and  501  -  Supportability  Test,  Evaluation,  and 
Verification. 

Subtask  401.2.11  -  LSAR  Updates.  The  development  of  the  LSAR  is  an 
ongoing  effort,  becoming  more  complete  and  detailed  as  the  new  system 
and  support  system  designs  evolve  and  mature.  It  is,  however, 
necessary  to  use  the  LSAR  data  as  it  evolves.  This,  in  turn,  requires 
updating  the  data  as  the  LSA  process  continues  to  ensure  the  latest 
information  is  available. to  all  ILS  element  managers  and  decision 
makers . 


Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  the 
iterative  nature  of  the  LSA  process.  For  example,  as  new  LSA  data  is 
developed  due  to  evolving  design  of  the  new  system,  the  LSAR  must  be 
updated  to  reflect  the  latest  status  of  the  particular  ILS  element 
analysis . 


Output . 

Performance  of  this  task  is  completed  during  the  FSD  Phase  with  the 
exception  of  updates  that  will  be  required  to  incorporate  Design 
Change  Notice  activity.  This  information  will  further  be  used  to 
update  the  logistics  products  which  were  initially  developed  from  the 
LSAR  documentation  by  feeding  the  change  information  back  into 
subtask  401.2.10  ILS  Output  Products. 

b.  Task  402  -  Early  Fielding  Analysis. 

Definition. 

The  purpose  of  this  task  is  to  determine  the  effect  the  introduction 
of  the  new  system  on  the  existing  support  infrastructure.  It 
provides  an  early  assessment  of  support  problems  which  are  likely  to 
be  encountered. 


This  task,  which  is  started  in  FSD  takes  the  support  system  as 
designed  and  compares  it  to  the  capabilities  of  the  existing  support 
organizations.  It  involves  the  following  four  (4)  subtasks: 


o  Subtask  402.2.1 
o  Subtask  402.2.2 
o  Subtask  402.2.3 
o  Subtask  402.2.5 


-  New  System  Impact 

-  sources  of  Manpower  and  Personnel  Skills 

-  impact  of  Resource  Shortfalls 
•  Plans  for  Problem  Resolution 
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Subtask  Procedures. 


Subtask  402.2.1  -  New  System  Impact.  The  purpose  of  this  subtask  is 
to  outline  the  impact  of  the  new  system  on  operating  locations  and 
the  logistics  infrastructure. 

Input. 

Input  to  this  subtask  is  derived  from  the  LSAR  data  base  and 
Government  information  concerning  manpower  and  personnel  and  support 
item  resources . 

Output . 

Performance  of  this  task  is  started  during  this  phase  and  completed 
during  production  when  all  design  changes  have  been  incorporated. 

The  output  of  this  subtask  highlights  actions  required  to  minimize 
adverse  impact  on  the  logistics  infrastructure  created  by  the  new 
system.  For  example,  design  changes  may  be  required  to  improve 
reliability  and  maintainability  so  as  to  reduce  logistics 
requirements . 

Subtask  402.2.2  -  Sources  of  Manpower  and  Personnel  Skills.  The 
purpose  of  this  subtask  is  to  compare  the  proposed  new  system 
manpower  and  personnel  requirements  to  those  likely  to  be  available 
at  the  time  the  system  is  placed  into  operation. 

Input . 

The  major  input  to  this  subtask  is  derived  from  the  LSAR  data  base 
and  Government  information  concerning  projected  manpower  and 
personnel  resources. 

Output . 

Performance  of  this  subtask  is  started  during  this  phase  and 
completed  during  the  Production  Phase  once  all  design  changes  have 
been  addressed  and  the  LSAR  information  updated.  The  output  of  this 
subtask  is  to  identify  sources  of  manpower,  and  personnel  skills,  and 
to  minimize  adverse  impact  on  this  resource  created  by  the 
introduction  of  the  new  system  into  the  operational  environment.  For 
example,  if  a  shortage  of  certain  skills  is  identified,  it  may  be 
necessary  to  increase  recruiting  and/or  conduct  additional  on-the-job 
training  to  overcome  the  shortage. 

Subtask  402.2.3  -  Impact  of  Resource  Shortfalls.  The  purpose  of  this 
subtask  is  to  assess  the  impact  of  support  resources  shortfalls  on 
system  availability.  This  assessment  can  be  made  through  several 
means.  For  example,  (1)  Subtask  303.2.4  -  Sensitivities,  (2) 
modeling  using  tools  such  as  Availability  Centered  Inventory  Model 
(ACIM),  (3)  relating  support  resource  budgets  to  system  availability, 
etc.  This  subtask  provides  the  quantitative  basis  for  the 
development  of  budget  requirements. 

Input . 
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Input  to  this  subtask  is  derived  from  Subtask  303.2.4  - 
Sensitivities,  and  the  use  of  existing  modeling  techniques  such  as 
ACIM,  sparing  to  availability  to  name  a  few. 

Output . 

Performance  of  this  subtask  is  started  in  this  phase  and  completed  in 
the  Production  Phase  to  accommodate  design  changes.  This  subtask 
shows  the  effect  on  system  availability  for  varying  levels  of  support 
resources  and  provides  the  basis  for  budget  requirements. 

Subtask  402.2.5  -  Plans  for  Problem  Resolution.  This  subtask  is 
concerned  with  routine  management  actions  required  to  develop  plans 
designed  to  correct  the  deficiencies  identified  by  the  previous 
subtasks . 

Input : 

There  is  no  input,  as  such,  to  this  subtask  in  that  it  ..equires 
development  of  solutions  to  problems  uncovered  earlier. 

Output . 

Performance  of  this  subtask  is  started  during  this  phase  and  updated 
in  the  Production  Phase  to  accommodate  design  changes .  This  subtask 
provides  the  plans  for  resolution  of  problems  discovered  in  the 
previous  efforts. 


4 . 2 . 4 . 4  Production  and  Deployment 
a.  Task  401.  Task  Analysis. 

During  the  Production  and  Deployment  phase  the  critical  issue  is  the 
recognition  that  all  support  planning  is  subject  to  change  for  a  host 
of  reasons.  Therefore,  it  is  mandatory  that  the  LSA  community  stay 
intimately  involved  with  Manufacturing  Engineering  to  track  and 
assess  the  impact  of  proposed  engineering  changes  and  that  field 
feedback  is  assessed  for  indications  that  support  decisions  may 
require  reassessment  and  shifts  in  established  support  concepts. 
Issues  such  as  technological  and  economic  life  may  require 
re-analysis  of  previously  established  repair  vs.  discard  decisions, 
the  introduction  of  new  technologies  or  the  elimination  of  vendor 
sourcing  may  alter  support  concepts . 

SMfeW*  . 2  . 11  -  LSAR  Updates.  The  maintenance  of  the  LSAR  is  a 
life  cycle  management  issue.  The  utility  of  an  LSAR  degrades  rapidly 
if  not  maintained  with  the  most  current  information.  It  is,  however, 
necessary  to  use  the  LSAR  data  as  it  evolves.  This,  in  turn, 
requires  updating  the  data  as  the  LSA  process  continues  to  ensure  the 
latest  information  is  available  to  all  ILS  element  managers  and 
decision  makers. 

Input . 
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During  this  phase,  input  to  this  subtask  is  derived  from  the 
iterative  nature  of  the  LSA  process.  For  example,  as  new  LSA  data  is 
developed  due  to  evolving  design  of  the  new  system,  the  LSAR  must  be 
updated  to  reflect  the  latest  status  of  the  particular  ILS  element 
analysis. 

Output . 

Performance  of  this  task  is  completed  during  the  FSD  Phase  with  the 
exception  of  updates  that  will  be  required  to  incorporate  Design 
Change  Notice  activity.  This  information  will  further  be  used  to 
update  the  logistics  products  which  were  initially  developed  from  the 
LSAR  documentation  by  feeding  the  change  information  back  into 
subtask  401.2.10  ILS  Output  Products. 
b.  Task  402  -  Early  Fielding  Analysis. 

Definition. 

The  purpose  of  this  task  in  this  phase  is  to  update  the  assessments 
of  fielding  and  is  to  refine  the  identified  effects  associated  with 
the  introduction  of  the  new  system  on  the  support  infrastructure.  It 
provides  critical  information  to  counter  anticipated  support 
problems . 

This  task,  which  was  started  in  FSD  takes  the  support  system  as 
designed  and  compares  it  to  the  capabilities  of  the  existing  support 
organizations.  The  updates  involve  the  same  four  (4)  subtasks  as 
identified  under  FSD. 


c.  Task  403  -  Post  Production  Support  Analysis 
Definition. 

The  purpose  of  this  task  is  to  determine  what  is  required  to  ensure 
that  the  new  system  will  be  supportable  after  initiation  of 
production  deliveries.  This  is  accomplished  by  updating  the 
information  developed  during  the  FSD  phase.  This  task,  which  is 
started  in  FSD  and  completed  during  the  Production  Phase,  is  composed 
of  one  (1)  subtask,  which  is  Subtask  403.2  Post  Production  Support 
Plan  (DI-P-711i? )  . 

Subtask  Procedures . 

Subtask  403.2  -  Post  Production  Support  Plan.  The  purpose  of  this 
subtask  is  to  develop  a  plan  for  implementing  effective  solutions  to 
post-production  support  problems  for  the  new  system.  The  plan  should 
consider  such  matters  as  vendor  sourcing,  modifications  to  allow 
incorporation  of  new  technologies,  system  availability  objectives, 
service  life  extension,  economic  life,  etc. 

Input . 

• 

Input  to  this  subtask  is  derived  from  Task  402  -  Early  Fielding 
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Analysis,  Subtask  501.2.4  -  Post  Deployment  Assessment  Plan,  Pre- 
Planned  Product  Improvement,  data  rights,  etc.  This  subtask  also 
should  be  accomplished  in  concert  with  Subtask  501.2.5  -  Post 
Deployment  Supportability  Assessment. 

Output . 

Performance  of  this  subtask  is  started  and  completed  as  early  as 
possible  in  the  Production  Phase.  The  result  of  this  effort  is  a  plan 
of  action  and  the  associated  funding  requirements  to  minimize  post¬ 
production  support  problems  for  the  new  system. 


4.2.5  Task  Section  500,  Supportability  Assessment. 

The  supportability  assessment  made  under  the  500  series  Tasks  are 
used  to  test  and  evaluate  the  new  system  design  concepts  or  designs 
at  various  stages  in  the  hardware  development  to  determine  if 
specified  supportability  requirements  are  being  met  and  the  degree  to 
which  they  are  being  achieved.  Any  shortcomings  are  identified  and 
corrective  measures  are  developed.  Supportability  data  from  Test  and 
Evaluation  (T&E)  and  operational  performance  reporting  aid  in  this 
assessment  and  the  formulation  of  corrective  actions . 

4 . 2 . 5 . 1  Concept  Exploration 

a.  Task  501  -  Supportability  Test.  Evaluation  and  Verification 
Definition. 

Task  501  determines  the  degree  to  which  supportability  goals  have 
been  met  and  deficiencies  have  been  corrected.  Unlike  the  more 
traditional  approach  to  testing,  this  Task  includes  test  and 
evaluation  of  the  support  system  performance.  It  is  comprised  of 
generally  two  (2)  areas  of  supportability. assessment:  (1)  assessment 
as  part  of  the  formal  Test  and  Evaluation  (T&E)  program,  and  (2) 
assessment  after  deployment  through  analysis  of  operational, 
maintenance,  and  supply  data  on  the  system  in  its  operational 
environment.  It  includes  the  performance  of  the  following  five  (5) 
subtasks: 


o  Subtask  501.2.1  -  Test  and  Evaluation  Strategy 

o  Subtask  501.2.2  -  Objectives  and  Criteria 

o  Subtask  501.2.3  -  Updates  ant  Corrective  Actions 

o  Subtask  501.2.4  -  Supportability  Assessment  Plan  (Post 

Deployment ) 

o  Subtask  501.2.5  -  Supportability  Assessment  (Post  Deployment) 

Subtask  Procedures. 

Subtask  501.2.1  -  Test  and  Evaluation  Strategy.  The  purpose  of  this 
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subtask  is  to  develop  the  supportability  test  and  evaluation 
planning.  This  includes  providing  a  basis  for  the  development  of 
test  and  evaluation  plans  for  DEM/VAL,  FSD  testing  and  Follow-on  Test 
and  Evaluation  (FOT&E).  T&E  strategies  must  reflect  the  established 
supportability  and  supportability  related  design  requirements; 
supportability  cost,  and  operational  availability  drivers;  and  areas 
associated  with  a  high  degree  of  risk. 

Input . 

During  this  phase  input  to  this  subtask  is  obtained  from  Tasks  203  - 
Comparative  Analysis,  205  -  Supportability  Design  Factors,  and  303 
Evaluation  of  Alternative  Tradeoff  Analysis  which  provide  information 
on  supportability  drivers,  past  problem  areas,  and  major  areas  of 
supportability  risks . 

Output . 

Performance  of  this  subtask  continues  into  DEM/VAL  and  provides  the 
basis  for  development  of  the  T&E  plans  for  supportability  testing  of 
the  new  system. 

4 . 2 . 5 . 2  Demonstration  and  Validation 

a.  Task  501  -  Supportability  Test.  Evaluation,  and  Verification 

This  task  was  initiated  during  the  CE.  However,  only  Subtask  501.2.1 
-  Test  and  Evaluation  Strategy  was  required  to  be  performed  during 
that  phase.  Performance  of  this  task  during  DEM/VAL  consists  of 
updating,  refining,  and  completing  Subtask  501.2.1  -  Test  and 
Evaluation  Strategy;  and  initiating  Subtasks  501.2.2  -  Objectives  and 
Criteria  and  501.2.3  -  Updates  and  Corrective  Actions.  The  remaining 
two  (2)  subtasks  501.2.4  -  Supportability  Assessment  Plan  (Post 
Production)  and  501.2.5  -  Supportability  Assessment  (Post  Production) 
will  be  started  in  FSD  and  Production,  respectively. 

Subtask  Procedures. 

Subtask  501.2.1  -  Test  and  Evaluation  Strategy.  As  stated  above, 
during  DEM/VAL  performance  of  this  subtask  consists  of  updating, 
refining,  and  completing  the  T&E  strategy  using  the  latest  data  as 
the  new  system  program  matures . 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  updated 
Tasks  203  -  Comparative  Analysis,  205  -  Supportability  Design 
Factors,  and  303  -  Evaluation  of  Alternative  Tradeoff  Analysis. 

Output . 

Performance  of  this  subtask  could,  in  part,  continue  into  the  FSD 
phase;  however,  it  should  be  completed  now  to  provide  a  firm  basis 
for  the  development  of  T&E  plans  for  DEM/VAL  and  FSD  of  the 
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supportability  T&E  program  for  the  new  system. 


Subtask  501.2.2  -  Objectives  and  Criteria.  The  purpose  of  this 
subtask  is  to  establish  test  plans  and  criteria  based  on  the  T&E 
objectives  of  the  new  system.  An  important  element  is  the 
identification  of  ILS  support  to  be  provided  to  the  testing 
activities . 

Input. 

During  this  phase,  input  to  this  subtask  is  derived  from  Tasks  301  - 
Functional  Requirements  Identification,  303  -Evaluation  of 
Alternatives  and  Trade  and  401  -  Task  Analysis. 

Output . 

Performance  of  this  subtask  continues  into  FSD  and  results  in 
detailed  test  plans  for  the  new  system. 

Subtask  501.2.3  -  Updates  and  Corrective  Actions .  The  purpose  of  this 
subtask  is  to  analyze  data  resulting  from  testing  in  order  to:  (1) 
correct  deficiencies  and  validate  corrective  actions;  (2)  update 
projections  for  readiness,  O&S  costs,  and  logistics  support  resource 
requirements;  (3)  determine  degree  of  improvement  required  in 
supportability  to  meet  established  goals;  (4)  evaluate  degree  of 
compliance  with  contractual  requirements;  (5)  provide  assessment  of 
supportability  as  an  input  into  the  material  acquisition  process;  (6) 
update  LSAR  data;  and  (7)  provide  a  data  base  to  be  used  for 
comparative  analysis  on  future  systems. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  data 
resulting  from  contractor  testing,  development  and  operational 
testing,  ILS  evaluations  of  contractor  achievement,  etc. 

Output . 

Performance  of  this  subtask  continues  into  the  FSD  Phase  with  only 
limited  activity  in  the  Production  Phase.  The  results  of  this  effort 
provided  data  as  outlined  in  the  seven  (7)  actions  delineated  above. 


4. 2. 5. 3  Full  Scale  Development. 

a.  Task  501  -  Supportabiltiv  Test.  Evaluation,  and  Verification 

This  task  was  initiated  during  CE  with  performance  of  Subtask  501.2.1 
-  Test  and  Evaluation  Strategy  which  was  completed  during  DEM/VAL. 
During  DEM/VAL,  Subtasks  501.2.2  -  Objectives  and  Criteria  and 

501.2.3  -Updates  and  Corrective  Actions  were  started.  During  this 
phase.  Subtasks  501.2.2  -  Objectives  and  Criteria,  and  501.2.3  - 
Updates  and  Corrective  Actions  will  be  essentially  completed.  The 
effort  during  this  phase  will  consist  of  updating  and  refining  these 


51 


two  (2)  subtasks  in  light  of  the  latest  data  made  available  as  the 
new  system  design  matures,  operational  scenario  and  environment, 
etc.,  become  refined;  and  the  initiation  of  Subtask  501.2.4  -  Post 
Deployment  Assessment  Plan.  Procedures  for  the  performance  of  these 
FSD  subtasks  are  described  below. 

Subtask  Procedures . 

Subtask  501.2.2  -  Objectives  and  Criteria.  The  test  plans  and 
criteria  developed  during  DEM/VAL  are  updated  during  this  phase. 
Further,  identification  of  the  ILS  support  to  be  provided  to  the  test 
activities  is  determined. 

Input. 

During  this  phase,  input  to  this  subtask  is  derived  from  updated 
Tasks  301  -  Functional  Requirements  Identification,  303  -  Evaluation 
of  Alter-  natives  and  Tradeoff  Analysis,  and  401  -  Task  Analysis. 

Output . 

Performance  of  this  subtask  is  essentially  completed  during  this 
phase  and  the  results  used  to  update  test  plans  for  the  new  system. 

Subtask  501.2.3  -  Updates  and  Corrective  Actions.  The  updates  and 
corrective  actions  started  during  the  preceding  phase  are  refined  and 
completed  during  this  phase.  Completion  of  the  six  (6)  actions  under 
this  subtask  (defined  in  the  DEM/VAL  Phase  for  this  subtask)  will 
minimize  problems  of  supportability  for  the  new  system  as  it  enters 
the  Production  Phase. 

Input . 

During  this  phase,  input  to  this  subtask  is  derived  from  updated 
(since  the  DEM/VAL  Phase  input)  contractor  testing,  development  and 
operational  testing,  ILS  evaluation  of  contractor  achievement,  etc. 

Output . 

Performance  of  this  subtask  is  completed  in  this  phase.  The  results 
of  this  effort  provide  completed  data  on  the  six  (6)  actions  under 
this  subtask  which  were  defined  in  DEM/VAL  for  this  subtask. 

Subtask  501.2.4  -  Post  Deployment  Assessment  Plan.  The  purpose  of 
this  subtask  is  to  develop  an  assessment  approach  which  will  provide 
the  necessary  data,  and  accuracy  of  data,  to  conduct  an  analysis. 

Care  must  be  exercised  to  assure  that  the  data  collected  is  from 
field  operations,  rather  than  an  activity  which  is  receiving  special 
attention,  e.g.,  contractor  support  personnel,  special  supply 
procedures,  extra  support  equipment,  etc.  In  the  event  existing 
standard  field  reporting  systems  will  not  provide  the  data  to  conduct 
an  analysis,  then  a  supplemental  data  collection  program  must  be 
planned,  approved,  budgeted  for,  and  implemented. 


Input . 


During  this  phase,  input  to  this  subtask  is  derived  from  Tasks  203  - 
Comparative  Analysis,  205  -  Supportability  and  Supportability  Related 
Design  Factors,  and  303  -  Evaluation  of  Alternatives  and  Tradeoff 
Analysis . 

Output . 

Performance  of  this  subtask  is  essentially  completed  during  this 
phase.  It  is  possible  some  updating  may  be  required  during  the  early 
part  of  the  Production  Phase.  Completion  of  this  effort  results  in  a 
plan  for  assessing  the  degree  to  which  supportability  goals  are  being 
achieved  and  to  identify  any  shortfalls. 


4 . 2 . 5 . 4  Production . 

a.  Task  501  -  Supportability  Test.  Evaluation,  and  Verification 

With  the  possible  exception  of  some  minor  updating,  all  subtasks 
except  Subtask  501.2.5  -  Post  Deployment  Supportability  Assessment 
were  basically  completed  by  the  end  of  the  Full  Scale  Development 
( FSD)  Phase.  The  effort  during  this  phase  will  consist  of  completing 
Subtask  501.2.5  -  Post  Deployment  Supportability  Assessment. 

Subtask  Procedures. 

Subtask  501.2.5  -  Post  Deployment  Supportability  Assessment. 
Performance  of  this  assessment  can  provide  significant  information 
for  system/ equipment  enhancements  through  logistics  support  resource 
modifications,  product  improvement  programs,  modification  of 
operating  programs ,  etc.  In  addition,  comparative  analysis  of  field 
results,  test  and  evaluation  results,  and  engineering  analysis  can 
provide  information  to  better  project  supportability,  cost,  and 
availability  parameters  on  future  acquisition  programs. 

Input . 

Input  to  this  subtask ,.is  derived  from  field  reporting  systems  and 
special  reporting  requirements  established  by  Subtask  501.2.4  -  Post 
Deployment  Assessment  Plan,  ILS  evaluations  of  contractor 
performance,  etc. 

Output . 

Performance  of  this  subtask  is  completed  during  this  phase.  This 
effort  defines  the  degree  to  which  supportability  goals  and 
parameters  have  been  met  and  provides  visibility  of  those  areas 
requiring  corrective  action.  Results  of  this  effort  should  be  used 
to  update  Subtask  403.2  -  Post  Production  Support  Plan. 


5 . 0  LSAR  Documentation  Procedures . 

The  detailed  entry  instructions  for  documentation  of  LSAR  data  are 
contained  in  Appendix  A  of  this  guide.  They  represent  a  tailored 
implementation  of  MIL-STD-1388-2A,  DoD  Requirements  for  a  Logistic 
Support  Analysis  Record.  They  have  been  modified  as  required  to 
support  the  ^information  requirements  as  reflected  in  the  LDIP  and 

LSAPR  documents .  These  procedures  will  be  updated  based  upon  changes 
and  refinements  in  the  Nav^adocumentation  needs. 

The  ft/V\5  LSAR  is  captured  in  an  automated  LSAR  using  the  ADP 

system.  This  system  has  demonstrated  its  capability  to  generate  LSAR 
Master  Files  which  are  compatible  with  the  u.S-  NP»vK|'£  "Class  II" 
LSAR  ADP  system.  It  is  envisioned  that  tffiVScP. will  likely  impose  or 
suggest  additional  automated  capabilities  as  their  sophistication  with 
the  LSAR  evolves.  The  (T3D)  software  offers  significant  import, 
processing  and  output  capabilities  that  can  easily  be  adapted  to  new 
interfaces,  processing  and  reporting  reouirements .  Figure  5-1 
identifies  the  major  segements  of  the  ft  N\5  LSAR  ADP  system. 


subcontractors  are  currently  in  the  process  of  demonstrating 
the  compatibility  with  the  database.  A  reverse 

demonstration  is  planned  to  ensure  that  all  subcontractors  can  import 
LSAR  information  from  GE/GCSD  in  order  to  eliminate  the  re-generation 
of  existing  documentation. 


5.1  LSAR  Documentation  Flow. 

The  development  of  the  LSAR  database  represents  the  combined 

efforts  of  the  Design,  Systems  Engineering  and  ILS  functional 
communities  of  T*\e  NC-SC.  Although  the  LSA 

Program  portion  of  the  ILS  Program  has  cognizance  over  the  LSAR 
development,  the  ultimate  quality  of  the  LSAR  information  is  directly 
dependent  upon  the  committment,  by  all  participating  organizations,  to 
it  quality,  currency  and  accuracy.  Detailed  in  the  following 
paragraphs  are  the  functional  area  responsibilities  for  the  generation 
of  the  inputs  to  the  LSAR  database. 

The  £vN\S  hardware  design  requirements  are  initially  established  by  the 
system  specification  developed  by  the  government.  These  requirements 
specify  system  level  requirements  and  constraints  representing  a 
combination  of  hardware  and  support  system  performance  characteristics. 
These  requirements  are  further  defined  to  establish  specific 
requirements  or  objectives  for  each  Supportability-related  program 
element.  Under  approach,  Front  End  Analysis  is  used  to 

ensure  that  support  related  considerations  such  as  manpower  and 
personnel,  testability,  standardization  and  transportability,  to  name 
just  a  few,  are  included  in  the  design  definition  process. 

All  Front  End  analyses  are  conducted  in  advance  or  concurrent  with  the 
evolution  of  the  hardware  design  to  ensure  that  the  'MasC-S  provides ,  not 
only  the  necessary  performance,  but  is  also  supportable  and  affordable 
in  the  operational  environment. 

Accomplishment  of  the  Front  End  analyses  is  divided  between  the  R&M, 
Human  Factors  Engineering,  Testability  and’ LSA  communities.  The 
analyses  consist  of  trade  studie  of  design  concepts  and  alternatives 
for  both  the  hardware/software  and  support  system.  The  results 
establish  hardware/software  and  support  system  design  requirements  and 
constraints  providing  the  best  balance  of  hardware  performance  and 
support  considerations. 

The  R&M  element  is  lead  in  the  conduct  of  SE/lLS-related  program  trade 
studies.  R&M  assesses  inherent  Reliability  and  Maintainability 
characteristics  of  each  alternative.  The  Human  Factors  Engineering 
community  compliments  these  activities  through  the  identification  of 
manpower  and  personnel  constraints,  deficiencies  in  human  factors 
characteristics  and  potential  health  hazard  and  safety  considerations. 
The  Integrated  Diagnostics /Testability  organization  establish 
testability  characteristics  necessary  to  achieve  the  required 
diagnostic  capabilities.  LSA  community  assess  each  alternative  to 
ascertain  operations  and  maintenance  requirements  to  include  the 
identification  of  individual  support  resource  requirements  and 
Operations  and  Support  (O&S)  costs. 
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The  combined  results  are  used  for  selection  or  identification  of 
preferred  design  alternatives  for  feedback  to  the  design  community. 

As  proposed  designs  are  formulated  by  Design  Engineering  they  are 
reviewed  and  analyzed  by  the  Participating  organizations.  The  review 
and  analysis  serves  to:  (1)  verify  achievement  of  objectives,  and;  (2) 
initiate  the  support  system  development  activities .  This  involves  each 
of  the  Participating  organizations  elements . 

The  design  information  during  initial  design  phase  consists  of 
preliminary  designs.  Through  the  iterative  process  of  analysis, 
evaluation  and  feedback  by  SE/ILS  and  other  Systems  Engineering 
disciplines  these  preliminary  designs  were  continually  refined  and 
updated.  The  level  of  analysis  was  directly  related  to  the  status  of 
the  design  information.  During  the  advanced  development  program  the 
t^r(\S  design  will  be  completed  and  the  support-related  information 
documented  in  the  LSAR  portion  of  the  ftftSDQ  database.  The  following 
paragraphs  describe  the  role  of  the  individual  Participating 
organizations  elements  in  the  conduct  of  the  design  analysis  portion  of 
the  LSA  process. 

Reliability  &  Maintainability  ( R&M) 

R&M  provides  the  primary  interface  of  the  participating  organizations 
with  the  Design  Engineering  community.  They  are  responsible  for  the 
initial  SE/ILS  analysis  of  the  design  to  determine  whether  or  not  the 
design  supports  attainment  of  system  R&M  requirements.  The 
characteristics  are  identified  and  quantified  as  described  in  the 
Reliability  Process  Requirements  document.  The  LSAR  database  is 
updated  with  R&M  data  by  LSA  program  element  using  the  documentation 
procedures  contained  in  the  LSA  Implementation  Guide.  The  R&M  design 
information  is  translated  into  the  LSAR  documentation  format  so  that  it 
is  available  to  all  participating  organizations  elements  through  the 
established  interface.  Under  this  approach  the  LSAR  serves  as  an 

evolving  baseline  database  that  is  continually  updated  to  the  most 
current  design  configuration. 

R&M  is  responsible  for  generation  of  the  R&M  characteristics  contained 
in  LSAR  database.  Specifically,  they  are  responsible  for:  (1) 
Quantifying  hardware  R&M  characteristics  of  the  design,  with  assistance 
from  LSA,  in  a  top-down  hardware  generation  breakdown  of  the  system, 
and;  (2)  Input  of  the  LSAR  B/B1/B2  Records. 

The  LSAR  B  Record  contains  descriptive  information  relative  to  an 
item's  physical  location  within  the  system  breakdown,  its  function,  any 
qualitative  Maintainability  characteristics  and  quantitative  R&M 
parameters.  The  quantitative  R&M  parameters  reflect  the  allocations 
required  to  meet  established  requirements  and  constraints.  As  the 
design  matures  the  allocations  are  updated  with  predicted  values  and 
finally  measured  values  based  upon  FSD  R&M  demonstrations  end  test 
results . 

R&M  conducts  a  Failure  Modes  and  Effects  Analysis  (FMEA).  The  FMEA 
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identifies  the  manner  in  which  an  item  can  fail  and  forms  the  basis  for 
the  Maintenance  Planning  process  to  be  conducted  by  the  LSA  element  of 
the  ILS  program.  R&M  documents  the  FMEA  results  on  the  LSAR  B1  Record 
and  updates  the  B  Record  R&M  characteristics  predictions .  This 
documentation  is  accomplished  in  accordance  with  the  approved  LSAR 
Documentation  Procedures  Guide. 

Designs  which  fail  to  meet  established  requirements  are  identified  back 
to  the  Design  Engineering  community  for  resolution  and  are  not  further 
analyzed  within  the  Participating  organizations.  Those  designs  which 
satisfy  established  requirements  and  constraints  are  made  available 
through  the  RtflSQ.0  database  to  the  Human  Factors  Engineering,  Integrated 
Diagnostics  and  Testability  and  ILS  functional  communities. 

As  the  design  evolves,  R&M  updates  the  FMEA  information  until  a 
complete  set  of  FMEA  data  has  been  developed  for  each  potentially 
repairable  item  in  the  hardware  breakdown.  The  Maintainability 
Information  analysis  marries  up  a  corrective  maintenance  action  to  each 
identified  failure  mode  contained  in  the  FMEA  data.  The  end  result  is 
a  set  of  corrective  maintenance  requirements  for  each  potentially 
repairable  item  within  the  complete  system  breakdown. 

As  deficiencies  in  the  hardware /software  and  support  system  designs 
are  identified  through  analysis  by  the  other  SE/ILS-related  program 
elements  the  results  are  communicated  back  to  the  R&M  community  for 
review  and  concurrence.  Collective  recommendations  are  developed  and 
provided  back  to  the  design  community  for  further  consideration  and 
resolution. 

Integrated  Diagnostics /Testability 

The  Integrated  Diagnostic/Testability  engineers  use  the  FMEA 
information  to  establish  testability  characteristics  of  the  system. 

They  conduct  analyses  to  determine  the  capabilities  of  the  Built-In- 
Test  (BIT)  of  individual  components  and  of  the  total  system.  They 
review  and  evaluate  the  adequacy  of  component  test  points  and  sensor 
placement.  This  information  is  documented  in  the  LSAR  in  the  BIT 
Application,  Logistics  Considerations  and  Maintainability 
Characteristics  data  fields.  Diagnostic  fault  trees,  developed  using 
FMEA  information  and  automated  Test  Program  Set  (TPS)  design  tools,  are 
prepared.  This  information  is  used  to  evaluate  the  on-board  Fault 
Detection  and  Isolation  System  (FDIS)  and  the  Fault  Isolation 
procedures  to  be  included  in  the  maintenance  procedures.  The 
Diagnostic  engineers  identify  specific  TPS  requirements  to  include  the 
individual  test  programs,  test  program  instructions  and  the 
interconnecting  devices  for  each  identified  Unit  Under  Test  ( UUT) . 

This  information  is  documented  in  the  LSAR  on  the  B/B1,C,D/D1,  and  E/E2 
Records . 

Logistic  Support  Analysis 

The  LSA  community  initiates  the  Maintenance  Planning  portion  of  the  ILS 
program.  Using  the  R&M  information  contained  in  the  LSAR,  the  LSA 
program  performs  two  key  analyses.  The  first  is  the  Level  of  Repair 
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Analysis  (LORA).  The  LORA  is  accomplished  using  the  approved  EDCAS 
model  and  consists  of  a  detailed  analysis  to  make  a  Repair  versus 
Discard  decision  for  each  potentially  repairable  item.  If  it  is 
determined  that  the  item  can  be  repaired  economically/  then  the  EDCAS 
provides  a  recommendation  for  the  level  of  maintenance  at  which  the 
repair  should  be  accomplished. 

Those  selected  for  discard  at  failure  are  not  further  analyzed  and  are 
treated  as  non-repairable  components  of  their  immediate  next  higher 
assembly.  No  tasks  are  written  against  these  items. 

Items  selected  for  repair  are  identified  as  reparables  and  are 
subjected  to  a  detailed  Task  Analysis  for  each  of  the  identified 
corrective  actions  indicated  by  the  FMEA  information.  Items  selected 
for  repair  at  failure  are  documented  in  the  LSAR  on  an  LSAR  C  Record 
by  the  LSA  community  prepares .  The  C  Record  identifies  each  separate 
corrective  action  to  be  accomplished  against  a  reparable  item. 

The  second  analysis  performed  by  the  LSA  community  is  the  Reliability 
Centered  Maintenance  (RCM)  analysis.  The  RCM  analysis  is  a  decision 
logic  which  builds  upon  the  FMEA  data  provided  by  R&M.  Through  the  RCM 
process  all  preventive  or  scheduled  maintenance  actions  are  identifxed. 
The  RCM  logic  results  are  documented  by  the  LSA  community  on  the  B 
Record.  Each  scheduled  maintenance  task  for  an  item  is  added  to  the  C 
Record  for  that  item.  The  combination  of  the  LORA  and  RCM  analyzes 
identifies  all  of  the  corrective  and  preventive  maintenance 
requirements  for  each  assembly. 

In  addition  to  the  corrective  and  preventive  actions,  the  LSA  community 
is  responsible  for  the  conduct  of  analyses  of  the  system  operations  to 
identify  "other"  support  tasks.  These  tasks  include  actions  such  as 
mission  profile  changes,  .transport  preparation,  depot  classification 
and  screening  and  fault  location  requirements.  They  are  identified 
through  the  analysis  of  C&TS  operations  using  established  NtW'j 
procedures.  In  addition  to  those  support  tasks  identified  through 
analysis  of  planned  field  operations,  suppprt  tasks  based  upon  an 
analysis  of  depot  operations  obtained  through  the  Depot  Study  are  also 
identified.  These  tasks  are  consolidated  on  the  LSAR  C  Records  for  the 
items  to  which  they  pertain.  At  this  point  the  completed  C  Record  for 
an  item  contains  all  of  the  operations  and  maintenance  tasks  that  must 
be  accommodated  by  the  support  system  and  identifies  the  anticipated 
frequency  per  year  of  normal  operations  for  each. 

Integrated  Logistic  Support  (ILS) 

For  each  task  identified  against  an  item,  the  Maintainability/LSA 
communities  conducts  a  Task  Analysis.  The  initial  Task  Analysis 
conducted  by  Maintainability  consists  of  the  basic  actions  or 
procedural  steps  to  be  accomplished  in  performance  of  the  task. 
Maintainability/LSA  communities  identify  individual  support  resource 
requirements  for  each  task.  The  LSA  community,  supported  by  the 
individual  ILS  functional  elements  and  other  SE/ILS-related  program 
elements,  further  analyze  the  task  requirements.  They  are  documented 
in  the  LSAR  on  the  D  and  D1  Records  and  through  the  this 

information  is  reviewed  by  the  subject  matter  experts  (SMEs)  from  the 
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R&M,  Training  and  ILS  functional  disciplines. 

The  Technical  Publications  community  uses  the  task  analysis  information 
as  source  data  for  development  of  the  technical  publications .  They 
apply  target  audience  considerations  such  as  reading  grade  levels,  task 
environment,  hardware  sensitivity  to  incorrect  performance,  as  well  as, 
safety  and  health  hazard  conditions.  The  refined  the  task  descriptions 
include  all  notes,  cautions  and  warnings  to  be  included  in  the 
individual  publications .  The  task  descriptions  contained  in  the  LSAR 
are  being  used  to  provide  technical  publication  narrative  data  base  and 
are  transferred  to  the  automated  authoring  system  electronically. 

Support  Equipment  engineers  evaluate  the  task  based  upon  support 
equipment  requirements  and  select  the  appropriate  items  to  be  used. 

The  Support  Equipment  engineers  coordinate  the  Diagnostic  personnel 
define  procedures  for  using  Test  Program  Sets  (TPSs)  in  conjunction 
with  the  use  of  Automatic  Test  Equipment  (ATE) . 

Facilities  engineering  reviews  the  tasks  to  determine  new  or  modified 
facility  requirements.  The  Depot  Study  and  site  surveys  of  operational 
sites  provide  the  baseline  for  this  identification.  New  or  modified 
facility  requirements  are  documented  by  the  Facilities  engineer  on  the 
LSAR  F  Record. 

The  Training  community  assigns  individual  personnel  responsibilities 
for  performance  of  each  task  documented  in  the  LSAR.  Based  upon  the 
personnel  assignments  made  by  the  Training  community  for  each  task,  a 
personnel  and  skill  analysis  will  be  conducted.  The  results  of  the 
training  analysis  are  documented  on  the  D1  Record  for  the  task  and 
provide  an  assessment  regarding  the  adequacy  of  the  assigned  personnel 
skill  to  perform  the  task.  In  addition,  based  upon  frequency  of 
performance  or  consequences  of  inadequate  performance,  a  training 
recommendation  is  established  for  each  task.  This  information  forms 
the  basis  for  development  of  the  training  programs.  Requirements  for 
modification  of  formal  service  training  school  programs  of  instruction, 
the  programs  which  result  in  an  individual's  personnel  skill  identifier 
are  further  defined  and  justified  on  the  LSAR  G  Record. 

When  the  Support  Equipment  Engineer  identifies  the  requirements  for  a 
new  or  peculiar  piece  of  support  equipment,  then  they  complete  an  LSAR 
E  and  El  Record.  In  the  event  the  E  and  El  Record  represents  an  item 
of  Automatic  Test  Equipment,  then  an  E2  Record  is  prepared  for  each 
item  of  the  system  or  Unit  Under  Test  (UUT)  that  will  be  tested  using 
the  piece  of  ATE.  The  Support  Equipment  Engineering  is  assisted  in  the 
preparation  of  the  E  Records  for  ATE  by  the  Diagnostic  engineers  in 
identifying  the  specific  TPS  requirements  to  test  each  designated  UUT. 

The  Supply  Support  community  uses  the  results  of  the  Task  Analysis 
to  identify  spare  and  repair  parts  requirements,  quantities  and 
stockage  distribution.  This  information  is  contained  on  the  LSAR  D1 
Record  (D07  Card).  The  Provisioning  element  of  the  Supply  Support 
functional  area  complete  the  LSAR  H  and  HI  Records  for  the  complete 
system  breakdown.  When  coupled  with  the  approved  engineering  drawings 
and  the  Supplemental  Provisioning  Technical  Documentation  (SPTD),  the 
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LSAR  H  and  HI  Record  information  provides  all  of  the  information 
requirements  for  Provisioning  Technical  Documentation  ( PTD ) . 

Working  in  consonance  with  the  Provisioning  community,  the  Technical 
Publications  community  assists  in  the  development  of  the  HI  Records. 
Their  inputs  are  used  to  define  the  requirements  for  the  Repair 
Parts/Special  Tools  List  ( RPSTL)  information  to  be  included  in  the 
Parts  Manuals.  The  Depot  activation  element  of  Supply  Support  area  use 
the  LSAR  documentation  to  establish  the  Depot  tooling  and  parts 
stockage  needed  to  support  the  pilot  Depot  Rework  and  Overhaul  program. 
The  packaging  requirements  for  each  hardware  item  is  developed  by  the 
packaging  engineering  community.  This  data  is  added  to  the  previously 
established  LSAR  H  records. 

Based  upon  the  identified  shuttle  launch  and  load  limitations 
the  Transportatability  community  define  the  transportability 
engineering  characteristics  of  the  RlflS  component  and  replenishment 
spares  in  their  shipping  configuration.  This  information  is  documented 
on  the  LSAR  J  Record.  Major  items  shipped  unsectionalized  will  have  a 
single  J  Record.  If  sectionalized  for  transport,  a  separate  J  Record 
will  be  prepared  for  each  section. 

Human  Factors  Engineering 

The  Human  Factors  Engineering  community,  as  previously  discussed,  is 
heavily  involved  in  the  Front  End  Analysis  portion  of  the  process.  As 
specific  tasks  are  identified  the  Human  Factors  Engineering  community 
serves  as  a  reviewing  activity  of  the  maintenance  planning  and  training 
requirements  results.  Personnel  task  assignments  are  reviewed  by  means 
of  the  interface  to  identify  opportunities  for  personnel  skill 

consolidation  and  reductions  in  manpower  levels.  Tasks  are  reviewed 
for  identification  of  potential  or  real  safety  and  health  hazard 
conditions  in  the  performance  of  all  operations  and  maintenance  task 
requirements . 


